KR20240045929A - Method of update and electronic device therefor - Google Patents

Abstract

An electronic device including a memory and a processor is disclosed. The electronic device may configure update data and a first version of an operating system (OS) into a virtual partition and attempt to boot using the second version of the OS of the virtual partition. When booting, the electronic device may transmit result information indicating whether booting based on the second version of the OS is successful to the security area, and determine whether to update version information in the security area based on the result information.

Description

Update method and electronic device therefor {METHOD OF UPDATE AND ELECTRONIC DEVICE THEREFOR}

Embodiments disclosed in this document relate to an update method and an electronic device for the same.

Electronic devices may operate based on various operating systems (OS). An operating system may include various functions for hardware control and software control of electronic devices. For example, an operating system can control various hardware components of an electronic device through a kernel. An operating system may include a framework to support the operation of various applications. A user of an electronic device can control the electronic device according to support of the operating system.

The operating system can be updated. Update may mean changing to a new version of the operating system by updating at least part of the old version of the operating system. For example, the operating system may be updated for a variety of reasons, such as fixing malfunctioning, fixing security vulnerabilities, improving convenience, and improving compatibility. The electronic device may include a function to prevent roll-back of the operating system. Rollback of an operating system may mean reverting a new version of the operating system to an older version of the operating system. For example, a new version of the operating system may complement abnormal functions and/or security vulnerabilities of the old version of the operating system. If a user rolls back the operating system to an older version of the operating system, normal operation of the electronic device cannot be guaranteed due to abnormal functions and/or security vulnerabilities.

The above information may be provided as background art for the purpose of aiding understanding of the present disclosure. No claim or determination is made as to whether any of the foregoing may apply as prior art with respect to the present disclosure.

An electronic device according to an embodiment disclosed in this document may include a memory and a processor. The memory may include a first area where a first version of an operating system (OS) is installed, a second area different from the first area, and a security area where version information of the OS is stored. The processor may store update data corresponding to the second version of the OS in the second area. The processor may set a part of the second area and a part of the first area where update data is stored as a virtual partition. The processor may attempt to boot using the second version of the OS installed in the virtual partition. The processor can forward the result of booting to the secure area. The processor may determine whether to change the version information stored in the security area based on the results.

In addition, a method for update management of an electronic device including a memory and a processor according to an embodiment disclosed in this document includes a portion of the data area of the first version of the OS installed in the first area of the memory and the The operation may include setting the data area of the second version of the update data stored in the second area as a virtual partition. The method may include attempting to boot using the second version of the OS installed in the virtual partition. The method may include transferring the result of the booting to a secure area of the memory. The method may include determining whether to change the version information of the OS stored in the security area based on the result.

Additionally, a computer-readable storage medium according to an embodiment disclosed in this document may store instructions that, when executed, cause the processor to perform operations. The operations may include setting a part of the data area of the first version of the OS installed in the first area of the memory and the data area of the second version of the update data stored in the second area of the memory as a virtual partition. You can. The operations may include attempting to boot using the second version of the OS installed in the virtual partition. The operations may include transferring the result of the booting to a secure area of the memory. The operations may include determining whether to change the version information of the OS stored in the security area based on the results.

1 is a block diagram of an electronic device according to an embodiment.
Figure 2 shows a memory structure of an electronic device according to an embodiment.
Figure 3 shows the configuration of a virtual partition according to one embodiment.
Figure 4 shows an updated operating system according to one embodiment.
Figure 5 shows modules of an electronic device according to one embodiment.
Figure 6 is a signal flow diagram of a method for updating an electronic device according to an embodiment.
7 is a signal flow diagram of a method for updating an electronic device according to an embodiment.
8 is a flowchart of a method for updating an electronic device according to an embodiment.
9 is a block diagram of an electronic device in a network environment, according to various embodiments.
Figure 10 is a block diagram illustrating a program 940 according to various embodiments.
In relation to the description of the drawings, identical or similar reference numerals may be used for identical or similar components.

Hereinafter, various embodiments of the present invention are described with reference to the accompanying drawings. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include various modifications, equivalents, and/or alternatives to the embodiments of the present invention.

1 is a block diagram of an electronic device according to an embodiment.

According to one embodiment, the electronic device 101 may include a processor 120, a memory 130, and/or a communication circuit 190. For example, the electronic device 101 may correspond to the electronic device 901 of FIG. 9 . For example, processor 120 may correspond to processor 920 of FIG. 9 . For example, memory 130 may correspond to memory 930 of FIG. 9 . For example, the communication circuit 190 may correspond to the communication module 990 of FIG. 9 . The structure of the electronic device 101 shown in FIG. 1 is illustrative, and the embodiments of this document are not limited thereto. For example, the electronic device 101 may further include a configuration not shown in FIG. 1 (eg, a configuration of the electronic device 901 in FIG. 9 ).

The processor 120 may be electrically, operatively, or functionally connected to the memory 130 and/or the communication circuit 190. In the present disclosure, when one component is “operably” connected to another component, it may mean that one component is connected to operate the other component. For example, one component may actuate another component by transmitting a control signal to the other component, either directly or via another component. In the present disclosure, when one component is “functionally” connected to another component, it may mean that one component is connected to execute the function of the other component. For example, one component may execute the function of another component by transmitting a control signal to the other component directly or via another component.

Memory 130 may store instructions. When executed by the processor 120, the instructions may cause the electronic device 101 to perform various operations. In this disclosure, the operation of the electronic device 101 may be referred to as an operation performed by the processor 120 by executing instructions stored in the memory 130. In the present disclosure, the operation of the electronic device 101 or the processor 120 may be referred to as an operation performed by executing instructions stored in a computer-readable storage medium. For example, computer-readable storage media may include non-transitory storage media.

In one embodiment, the memory 130 may include a general area 140 and a security area 150. The general area 140 is a normal memory area and may be a memory area operated by a general OS. The security area 150 is a trusted memory area and may be a memory area operated by a secure OS. For example, the general area 140 may be referred to as a memory area within a Rich Execution Environment (REE). For example, the security area 150 may be referred to as a memory area within a Trusted Execution Environment (TEE). Descriptions of the general area 140 and the security area 150 may be described later with reference to FIG. 2 .

Communication circuitry 190 may provide communication between electronic device 101 and other electronic devices (e.g., electronic device 902, electronic device 904, and/or server 908 of FIG. 9). Communication circuitry 190 may support wired and/or wireless communication. Communication circuitry 690 may support short-range wireless communication and/or long-range wireless communication. In one example, the electronic device 101 may receive update data from another electronic device using the communication circuit 190.

According to one embodiment, the electronic device 101 may update the OS stored in the memory 130. For example, the electronic device 101 may update the OS based on user input or may update the OS at a designated time. For example, the electronic device 101 may update an old version of the OS to a new version of the OS by recording update data in a part of the old version of the OS.

The electronic device 101 may support a roll back prevention (RP) function. In one example, RP version information may be stored in the secure area 150. When an update is attempted, the electronic device 101 may not perform the update if the RP version of the image to be updated (e.g., the binary of the OS to be updated) is lower than the stored RP version. By preventing updates based on low RP versions, the electronic device 101 can support RP functionality. RP version information may include, for example, version information of the OS to be updated, a security counter, or any version information. In one example, the electronic device 101 may support the RP function by preventing an image (e.g., OS binary) of a lower version than the stored RP version from being executed.

The electronic device 101 may perform an update using a virtual partition. The electronic device 101 may set up a virtual partition that includes part of an old version of the OS and update data of a new version of the OS. Using the new version OS in the virtual partition, the electronic device 101 may attempt to boot based on the new version OS. For example, during the booting process, the electronic device 101 may record the RP version corresponding to the new version OS in the memory 140 according to a designated process (eg, a boot loader process). However, problems may occur during the update process. For example, booting based on the updated OS may not complete. Due to incomplete booting, problems such as infinite booting errors may occur. However, due to the RP function, OS rollback may not be performed. Even if an older version of the OS is stored in a memory area other than a virtual partition, the RP function can prevent the execution of the older version of the OS. According to one embodiment, the electronic device 101 may perform an update so as not to conflict with the RP function. Below, a method of updating the electronic device 101 may be described with reference to FIGS. 2 to 9 .

Figure 2 shows a memory structure of an electronic device according to an embodiment.

Referring to FIGS. 1 and 2 , the electronic device 101 can separate the execution environment of the electronic device 101 by operating a general area 140 and a security area 150. In one example, the general area 140 may refer to an execution environment and memory area operated by a rich OS 230 (e.g., the operating system 942 of FIG. 9). The security area 150 may refer to an execution environment and memory area operated by the trusted OS 280. The general area 140 and the security area 150 may be areas implemented by, for example, one processor 120. In one example, the security area 150 may be an area implemented by a chip including a separate memory and processor.

The general area 140 may include, for example, a normal application 210 and applications with secure OS support (220). The general application 210 (e.g., the application 946 in FIG. 9) may be an application that operates under the support of the rich OS 230 and may be referred to as a client application. The security OS support application 220 (e.g., the application 946 in FIG. 9) may be referred to as an application that can obtain data of the security area 150 under the support of the rich OS 230.

The security area 150 may be an execution environment separated from the general area 140. For example, the trusted OS 280 may operate independently of the rich OS 230. In one example, even if the rich OS 230 fails to boot, the trusted OS 280 may boot successfully. The security area 150 may correspond to the execution environment of the trusted applications 260 and 270. The trusted applications 260 and 270 are applications that satisfy specified security requirements and may be applications that operate under the support of the trusted OS 280.

In one example, trusted application 260 may interact with a secure OS support application 220 operating in general area 140 . The security OS support application 220 may request the trusted application 260 to perform a specified operation (e.g., a security-related operation) and receive a result value of the specified operation from the trusted application 260. The security OS support application 220 may use the received result value to perform, for example, a security-related operation (eg, authentication). In one example, the trusted application 260 may obtain a value stored in a memory area used by the secure OS support application 220. For example, the trusted application 260 may obtain the stored value by monitoring the memory area used by the secure OS support application 220.

The monitor 290 may be the primary interface between the general area 140 and the security area 150. For example, data in the general area 140 may be transmitted to the trusted application 270 in the security area 150 through the monitor 290. Data transmitted to the secure area 150 may be stored in the secure area 150 after authentication by the trusted application 270. For example, the security OS support application 220 of the general area 140 may obtain data of the security area 150 through the monitor 290.

According to one embodiment, the electronic device 101 may store the RP version in the secure area 150, as will be described later with reference to FIGS. 3 to 8. By storing the RP version in the security area 150, arbitrary rollback by a user or intruder can be prevented. The OS update discussed below may be referred to, for example, as an update of the OS corresponding to the rich OS 230 of FIG. 2 . With reference to FIGS. 3 and 4 , a method of updating the electronic device 101 may be described.

Figure 3 shows the configuration of a virtual partition according to one embodiment.

Referring to FIGS. 1 and 3 , the general area 140 may include a first area 310 and a second area 320 . For example, the first area 310 may correspond to the first partition of the general area 140, and the second area 320 may correspond to the second partition of the general area 140. The first partition and the second partition may be referred to as partitions rather than virtual partitions.

In one example, the first area 310 may be a memory area where an OS is installed. The first part 311 of the first area 310 may be, for example, a part where code implemented by an OS vendor is stored. The second part 312 may be a part where a code implemented by the supplier of the electronic device 101 is stored. The first part 311 may include first data 313, and the second part 312 may include second data 314. In the example of FIG. 3, the OS installed in the first area 310 may be referred to as the first version of the OS.

In one example, the electronic device 101 may store first update data 323 and second update data 324 in the second area 320 . The second area 320 may be, for example, an area where user data is stored. The first update data 323 may be referred to as update data for the first data 313, and the second update data 324 may be referred to as update data for the second data 324. The first update data 323 and the second update data 324 may be referred to as data for updating the first version of the OS stored in the first area 310 to the second version of the OS.

In the example of FIG. 3, the first data 313 and the second data 314 are illustrated as being updated, but embodiments of the present disclosure are not limited thereto. For example, either the first data 313 or the second data 314 may be updated.

According to one embodiment, the electronic device 101 may configure a virtual area 390. For example, virtual area 390 may be referred to as a virtual partition. The electronic device 101 includes the first part 311 including first update data 323 instead of the first data 313, and the second part 312 including the second update data 314 instead of the second data 314. Even if it includes data 324, a virtual area 390 can be formed. Since the virtual area 390 is formed while leaving the actual data as is, the first data 313 and the second data 314 may be stored in the first area 310 as is.

Because the virtual area 390 is configured to contain updated data, the virtual area 390 may include a second version of the OS. The electronic device 101 may attempt to boot using the OS (eg, OS image) of the virtual area 390.

Figure 4 shows an updated operating system according to one embodiment.

Referring to FIGS. 1, 3, and 4, according to one embodiment, when booting using the OS of the virtual area 390 of FIG. 3 is successfully completed, the electronic device 101 generates first update data 323. ) and second update data 324 may be recorded in the first area 310. For example, when booting using the OS of the virtual area 390 is successfully completed, the electronic device 101 may determine that the update has been successfully completed. The electronic device 101 may complete the update by recording update data in the first area 310 rather than the virtual area 390. For example, the electronic device 101 may record first update data 323 at the location of the first data 313 and record second update data 324 at the location of the second data 312. there is. When the update is completed, for example, the electronic device 101 may delete the first update data 323 and the second update data 324 stored in the second area 320.

In one example, the update may not complete successfully. For example, the electronic device 101 may fail to boot based on the OS of the virtual area 390. According to one embodiment, if the update fails, the electronic device 101 may attempt to boot using the first version of the OS stored in the first area 310 of FIG. 3. In this case, in order to prevent booting of the first version of the OS from being restricted due to the RP function, the electronic device 101 may perform an update according to a method described later with reference to FIGS. 5 to 8.

Figure 5 shows modules of an electronic device according to one embodiment.

Referring to FIGS. 1 and 5 , according to one embodiment, the electronic device 101 may set the RP version based on the update status. Configurations of the electronic device 101 described with reference to FIG. 5 may be referred to as software modules implemented by the processor 120 executing instructions. Operations of various components described later may all be referred to as operations of the electronic device 101.

According to one embodiment, the general area 140 may include an update status manager 510, an update status partition 520, and an RP module 530. The update status partition 520 may be referred to as a memory area in which the update status of the electronic device 101 is recorded. For example, the RP module 530 may be a module that prevents a binary (e.g., OS image) of a lower RP version than the RP version recorded in the RP version DB 580 from being executed. The RP module 530 may be referred to as a module that performs the above-described RP function. In the example of FIG. 5, the RP module 530 is implemented on the general area 140, but embodiments of this document are not limited thereto. For example, RP module 530 may be implemented on secure area 150.

According to one embodiment, the update status manager 510 may transmit information indicating the booting result to the trusted update status reception module 560 when booting. For example, the update status manager 510 provides information to the trust update status reception module 560 through any interface (e.g., monitor 290 in FIG. 2) between the general area 140 and the security area 150. can be transmitted. The update status manager 510 may be code that is executed when the electronic device 101 boots. For example, the update status manager 510 may be implemented as part of a boot loader. For example, the update status manager 510 may be a daemon that can be executed independently from the booting of the OS.

The update status manager 510 may identify the update status stored in the update status partition 520 and obtain result information indicating the booting result based on the identified update status. The update state may include, for example, a first state, a second state, and/or an error state. The first state is a state in which the electronic device 101 is booted using the OS before the update (e.g., the first version of the OS stored in the first area 310 of FIG. 3) (e.g., using the previous version of the OS). It can mean an operating state). The second state is a state in which the electronic device 101 is booted using an updated OS (e.g., a second version of the OS stored in the virtual area 390 of FIG. 3 or the first area 310 of FIG. 4) ( Example: This may mean a state of operation using an updated version of the OS. An error state may mean a state that requires rollback due to an error or update failure.

In one example, the result information may further include additional information in addition to update status information (eg, first state, second state, or error state). For example, the result information may include time information (eg, time stamp) indicating the time at which the update status information was obtained. For example, the result information may include any necessary information in addition to the information described above.

According to one embodiment, the security area 150 may include a trust update status reception module 560, an RP version control module 570, and an RP version DB 580. The RP version DB 580 may be a memory area where the RP version is stored.

The trusted update status receiving module 560 may receive result information (e.g., update status information, time information, and/or arbitrary information) from the update status manager 510. The trust update status receiving module 560 may transmit the received result information to the RP version control module 570.

In one example, the trust update status receiving module 560 may perform authentication on the received result information. For example, the trust update status receiving module 560 may authenticate the result information using an encryption method, access code, and/or time information of the result information. If authentication of the result information is successful, the trust update status reception module 560 may transmit at least part of the result information to the RP version control module 570.

According to one embodiment, the RP version control module 570 manages the RP version information stored in the RP version DB 580 based on the result information (e.g., status information) received from the trust update status reception module 560. You can. For example, the RP version control module 570 may update the RP version information when the result information indicates a successful boot based on the updated OS. For example, the RP version control module 570 may store RP control information for each partition based on status information indicated by result information. The operation of the RP version control module 570 can be described with respect to FIGS. 6 and 7.

The electronic device 101 can prevent update errors caused by the RP function that may occur during the update by updating the RP version based on the result information. The electronic device 101 can supplement security vulnerabilities by determining whether to update the RP version in the security area 150 and recording the RP version.

Figure 6 is a signal flow diagram of a method for updating an electronic device according to an embodiment.

Referring to FIGS. 5 and 6 , according to one embodiment, the RP version control module 570 may store RP version information in the RP version DB 580 based on the result information. For example, the RP version DB 580 may store RP version information corresponding to an older version of the OS (e.g., the OS stored in the first area 310 of FIG. 3).

In operation 605, when the electronic device 101 boots, the update status manager 510 may identify the status of the update status partition 520. In operation 610, the update status manager 510 may transmit status information (eg, result information) to the update status reception module 560.

At operation 615, the update status reception module 560 may transmit status information to the RP version control module 570. For example, the update status receiving module 560 may perform authentication on the received status information and deliver the status information if the authentication is successful.

At operation 620, the RP version control module 570 may determine whether booting based on the updated OS was successful. For example, the RP version control module 570 may determine whether booting based on the updated OS was successful based on the received status information. For example, if the received state information indicates a second state (e.g., a state booted using an updated second version of the OS), the RP version control module 570 determines that booting based on the updated OS is successful. You can decide. For example, if the received state information indicates a first state (e.g., a state booted using a first version of the OS that is old) or an error state, the RP version control module 570 may perform booting based on the updated OS. You can decide that this has failed.

If booting based on the updated OS is successful (e.g., operation 620-YES), in operation 625, the RP version control module 570 may update the RP version stored in the RP version DB 580. For example, the RP version control module 570 may update the RP version information stored in the RP version DB 580 from the first RP version information to the second RP version information. For example, the first RP version information may be the RP version corresponding to the first version of the OS, and the second RP information may be the RP version corresponding to the second version of the OS.

If booting based on the updated OS fails (e.g., operation 620-NO), in operation 630, the RP version control module 570 may maintain the RP version stored in the RP version DB 580. For example, if the received result (e.g., status information) indicates a first state (e.g., booted using a first version of the OS that is older) or an error state, the RP version control module 570 The RP version information stored in the version DB 580 can be maintained as the first RP version information.

The RP module 530 can determine whether to prevent rollback using the RP version stored in the RP version DB 560. For example, if the update fails (e.g., operation 620-NO), the resulting information may indicate a first state or an error state. In this case, the RP version control module 570 may maintain the first RP version information (eg, operation 630). The RP module 530 may apply a rollback prevention function based on the first RP version information. Therefore, even if the update to the second version fails, a rollback to the first version OS can be performed. For example, if booting based on the second version of the OS stored in the virtual partition (e.g., virtual area 390 in FIG. 3) is successful (e.g., operation 620-YES), the resulting information may indicate the second state. You can. In this case, the RP version control module 570 may update the first RP version information with the second RP version information (eg, operation 625). The RP module 530 may apply a rollback prevention function based on the second RP version information.

7 is a signal flow diagram of a method for updating an electronic device according to an embodiment.

Referring to FIGS. 5 and 7 , according to one embodiment, the RP version control module 570 may store RP version information for each partition in the RP version DB 580. For example, the RP version DB 580 may store RP version information corresponding to an older version of the OS (e.g., the OS stored in the first area 310 of FIG. 3). RP version information corresponding to the first version of the OS, which is an older version, may be mapped to the first partition (e.g., the first area 310 in FIG. 3) and stored in the RP version DB 580.

In operation 605, when the electronic device 101 boots, the update status manager 510 may identify the status of the update status partition 520. In operation 610, the update status manager 510 may transmit status information (eg, result information) to the update status reception module 560. At operation 615, the update status reception module 560 may transmit status information to the RP version control module 570.

In operation 720, the RP version control module 570 may store RP version information in the RP version DB 580 based on the received status information. For example, the received state information may indicate a second state (eg, booted using an updated second version of the OS). The RP version control module 570 may map the RP version information corresponding to the second version of the OS with a virtual partition (e.g., the virtual area 390 in FIG. 3) and store it in the RP version DB 580. In this case, the RP version DB 580 contains first RP version information mapped to the first partition (e.g., RP version information corresponding to the first version of the OS) and second RP version information mapped to the virtual partition (e.g., RP version information corresponding to the second version of the OS) may be stored. Meanwhile, if the result information indicates an error state, the RP version control module 570 may not store the received result information in the RP version DB 580.

The RP module 530 can determine whether to prevent rollback using the RP version of the partition used for booting. For example, when the first version of the OS stored in the first partition (e.g., the first area 310 in FIG. 3) is used for booting, the RP module 530 stores the first RP mapped to the first partition. Rollback prevention function can be applied based on version information. Therefore, even if the update to the second version fails, a rollback to the first version OS can be performed. For example, when a second version of the OS stored in a virtual partition (e.g., virtual area 390 in FIG. 3) is used for booting, the RP module 530 based on the second RP version information mapped to the virtual partition. Thus, the rollback prevention function can be applied.

When booting based on the updated second version OS is successfully completed, the electronic device 101 may record update data in the first partition (eg, first area 310 of FIG. 3). For example, as shown in the first area 310 of FIG. 4, the OS in the first partition may be updated to the second version. In this case, the update status manager 510 may transmit result information indicating the result of booting based on the first partition to the RP version control module 570 through the trusted update status reception module 560. The RP version control module 570 may update the RP version information mapped for the first partition from the first RP version information to the second RP version information. Thereafter, in booting based on the first partition, the RP module 530 may apply the RP function based on the second RP information currently mapped to the first partition.

8 is a flowchart of a method for updating an electronic device according to an embodiment.

Referring to FIGS. 1 and 8 , according to one embodiment, the electronic device 101 may include a memory 130 and a processor 120. The memory 130 may store instructions that, when executed, cause the processor 120 to perform operations described later.

In operation 805, the electronic device 101 stores update data (e.g., first update data (e.g., first update data 323 and/or second update data 324 of FIG. 3)) in a second area (e.g., It can be stored in the second area 320 of Figure 3. For example, the electronic device 101 can receive update data from an external electronic device using the communication circuit 190 and store it in the memory 130. .

In operation 810, the electronic device 101 divides a portion of the second area and a portion of the first area (e.g., the first area 310 of FIG. 3) into a virtual partition (e.g., the virtual area 390 of FIG. 3). You can set it. By bundling a portion of the first version of the OS installed in the first area and update data stored in the second area to form one virtual partition, the virtual partition may have the updated second version of the OS installed. For example, the first area and the second area may be memory areas within a Rich Execution Environment (REE).

In operation 815, the electronic device 101 may boot using the second version of the OS installed in the virtual partition. Depending on the performance of booting, the electronic device 101 may identify the update status, as described above with respect to operation 605 of FIG. 6 .

In operation 820, the electronic device 101 may transmit the booting result to the security area (eg, the security area 150 in FIG. 2). For example, the security area may be a memory area operated based on a security OS (e.g., the trusted OS 280 of FIG. 2) that is different from the OS (e.g., the rich OS 230 of FIG. 2). As described above with respect to operations 610 and 615 of FIG. 6, the electronic device 101 may transmit booting results (e.g., status information) to the RP version control module 570 through the update status reception module 560. .

In operation 825, the electronic device 101 may determine whether to change version information (eg, RP version) stored in the security area based on the booting result. For example, as described above with regard to operation 620 of FIG. 6, the electronic device 101 may change version information depending on whether booting based on the updated OS is successful. For example, the electronic device 101 may change or maintain version information stored in the secure area based on the results using a program on the secure OS (e.g., RP version control module 570 in FIG. 5). For example, the security area may be a memory area within a Trusted Execution Environment (TEE). For example, version information may be information for determining OS rollback. The electronic device 101 may be set to prevent the OS from being rolled back to a version older than the version information stored in the security area.

For example, if the booting result indicates success, the electronic device 101 may change version information from the first version to the second version (eg, operation 625 of FIG. 6). After changing the version information, the electronic device 101 may update the OS of the first area to the second version of the OS by recording update data in a portion corresponding to the update data among the OS data of the first area. .

If the result indicates failure (e.g., operation 620-NO in FIG. 6), the electronic device 101 maintains the version information as the first version (e.g., operation 630 in FIG. 6), and stores the first version in the first area. You can try booting using version 1 of the OS. For example, if the result indicates booting using the first version of the OS (e.g., first state) or an error state, the electronic device 101 may determine that booting based on the updated OS failed.

FIG. 9 is a block diagram of an electronic device 901 in a network environment 900, according to various embodiments. Referring to FIG. 9, in the network environment 900, the electronic device 901 communicates with the electronic device 902 through a first network 998 (e.g., a short-range wireless communication network) or a second network 999. It is possible to communicate with at least one of the electronic device 904 or the server 908 through (e.g., a long-distance wireless communication network). According to one embodiment, the electronic device 901 may communicate with the electronic device 904 through the server 908. According to one embodiment, the electronic device 901 includes a processor 920, a memory 930, an input module 950, an audio output module 955, a display module 960, an audio module 970, and a sensor module ( 976), interface 977, connection terminal 978, haptic module 979, camera module 980, power management module 988, battery 989, communication module 990, subscriber identification module 996 , or may include an antenna module 997. In some embodiments, at least one of these components (eg, the connection terminal 978) may be omitted, or one or more other components may be added to the electronic device 901. In some embodiments, some of these components (e.g., sensor module 976, camera module 980, or antenna module 997) are integrated into one component (e.g., display module 960). It can be.

Processor 920 may, for example, execute software (e.g., program 940) to operate at least one other component (e.g., hardware or software component) of electronic device 901 connected to processor 920. It can be controlled and various data processing or calculations can be performed. According to one embodiment, as at least part of data processing or computation, the processor 920 stores instructions or data received from another component (e.g., sensor module 976 or communication module 990) in volatile memory 932. The commands or data stored in the volatile memory 932 can be processed, and the resulting data can be stored in the non-volatile memory 934. According to one embodiment, the processor 920 may include a main processor 921 (e.g., a central processing unit or an application processor) or an auxiliary processor 923 that can operate independently or together (e.g., a graphics processing unit, a neural network processing unit ( It may include a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor). For example, if the electronic device 901 includes a main processor 921 and a auxiliary processor 923, the auxiliary processor 923 may be set to use lower power than the main processor 921 or be specialized for a designated function. You can. The auxiliary processor 923 may be implemented separately from the main processor 921 or as part of it.

The auxiliary processor 923 may, for example, act on behalf of the main processor 921 while the main processor 921 is in an inactive (e.g., sleep) state, or while the main processor 921 is in an active (e.g., application execution) state. ), together with the main processor 921, at least one of the components of the electronic device 901 (e.g., the display module 960, the sensor module 976, or the communication module 990) At least some of the functions or states related to can be controlled. According to one embodiment, co-processor 923 (e.g., image signal processor or communication processor) may be implemented as part of another functionally related component (e.g., camera module 980 or communication module 990). there is. According to one embodiment, the auxiliary processor 923 (e.g., neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. Artificial intelligence models can be created through machine learning. For example, such learning may be performed in the electronic device 901 itself on which the artificial intelligence model is performed, or may be performed through a separate server (e.g., server 908). Learning algorithms may include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but It is not limited. An artificial intelligence model may include multiple artificial neural network layers. Artificial neural networks include deep neural network (DNN), convolutional neural network (CNN), recurrent neural network (RNN), restricted boltzmann machine (RBM), belief deep network (DBN), bidirectional recurrent deep neural network (BRDNN), It may be one of deep Q-networks or a combination of two or more of the above, but is not limited to the examples described above. In addition to hardware structures, artificial intelligence models may additionally or alternatively include software structures.

The memory 930 may store various data used by at least one component (eg, the processor 920 or the sensor module 976) of the electronic device 901. Data may include, for example, input data or output data for software (e.g., program 940) and instructions related thereto. Memory 930 may include volatile memory 932 or non-volatile memory 934.

The program 940 may be stored as software in the memory 930 and may include, for example, an operating system 942, middleware 944, or application 946.

The input module 950 may receive commands or data to be used in a component of the electronic device 901 (e.g., the processor 920) from outside the electronic device 901 (e.g., a user). The input module 950 may include, for example, a microphone, mouse, keyboard, keys (eg, buttons), or digital pen (eg, stylus pen).

The sound output module 955 may output sound signals to the outside of the electronic device 901. The sound output module 955 may include, for example, a speaker or receiver. Speakers can be used for general purposes such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. According to one embodiment, the receiver may be implemented separately from the speaker or as part of it.

The display module 960 can visually provide information to the outside of the electronic device 901 (eg, a user). The display module 960 may include, for example, a display, a hologram device, or a projector, and a control circuit for controlling the device. According to one embodiment, the display module 960 may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of force generated by the touch.

The audio module 970 can convert sound into an electrical signal or, conversely, convert an electrical signal into sound. According to one embodiment, the audio module 970 acquires sound through the input module 950, the sound output module 955, or an external electronic device (e.g., directly or wirelessly connected to the electronic device 901). Sound may be output through an electronic device 902 (e.g., speaker or headphone).

The sensor module 976 detects the operating state (e.g., power or temperature) of the electronic device 901 or the external environmental state (e.g., user state) and generates an electrical signal or data value corresponding to the detected state. can do. According to one embodiment, the sensor module 976 includes, for example, a gesture sensor, a gyro sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, It may include a temperature sensor, humidity sensor, or light sensor.

The interface 977 may support one or more designated protocols that can be used to connect the electronic device 901 directly or wirelessly with an external electronic device (e.g., the electronic device 902). According to one embodiment, the interface 977 may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

The connection terminal 978 may include a connector through which the electronic device 901 can be physically connected to an external electronic device (eg, the electronic device 902). According to one embodiment, the connection terminal 978 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (eg, a headphone connector).

The haptic module 979 can convert electrical signals into mechanical stimulation (e.g., vibration or movement) or electrical stimulation that the user can perceive through tactile or kinesthetic senses. According to one embodiment, the haptic module 979 may include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

The camera module 980 can capture still images and moving images. According to one embodiment, the camera module 980 may include one or more lenses, image sensors, image signal processors, or flashes.

The power management module 988 can manage power supplied to the electronic device 901. According to one embodiment, the power management module 988 may be implemented as at least a part of, for example, a power management integrated circuit (PMIC).

The battery 989 may supply power to at least one component of the electronic device 901. According to one embodiment, the battery 989 may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

Communication module 990 provides a direct (e.g., wired) communication channel or wireless communication channel between electronic device 901 and an external electronic device (e.g., electronic device 902, electronic device 904, or server 908). It can support establishment and communication through established communication channels. Communication module 990 operates independently of processor 920 (e.g., an application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module 990 is a wireless communication module 992 (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 994 (e.g. : LAN (local area network) communication module, or power line communication module) may be included. Among these communication modules, the corresponding communication module is a first network 998 (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network 999 (e.g., legacy It may communicate with an external electronic device 904 through a telecommunication network such as a cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., LAN or WAN). These various types of communication modules may be integrated into one component (e.g., a single chip) or may be implemented as a plurality of separate components (e.g., multiple chips). The wireless communication module 992 uses subscriber information (e.g., International Mobile Subscriber Identifier (IMSI)) stored in the subscriber identification module 996 within a communication network such as the first network 998 or the second network 999. The electronic device 901 can be confirmed or authenticated.

The wireless communication module 992 may support 5G networks after 4G networks and next-generation communication technologies, for example, NR access technology (new radio access technology). NR access technology provides high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and access to multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low latency). -latency communications)) can be supported. The wireless communication module 992 may support high frequency bands (e.g., mmWave bands), for example, to achieve high data rates. The wireless communication module 992 uses various technologies to secure performance in high frequency bands, for example, beamforming, massive array multiple-input and multiple-output (MIMO), and full-dimensional multiplexing. It can support technologies such as input/output (FD-MIMO: full dimensional MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module 992 may support various requirements specified in the electronic device 901, an external electronic device (e.g., electronic device 904), or a network system (e.g., second network 999). According to one embodiment, the wireless communication module 992 supports Peak data rate (e.g., 20 Gbps or more) for realizing eMBB, loss coverage (e.g., 164 dB or less) for realizing mmTC, or U-plane latency (e.g., 164 dB or less) for realizing URLLC. Example: Downlink (DL) and uplink (UL) each of 0.5 ms or less, or round trip 1 ms or less) can be supported.

The antenna module 997 may transmit or receive signals or power to or from the outside (e.g., an external electronic device). According to one embodiment, the antenna module 997 may include an antenna including a radiator made of a conductor or a conductive pattern formed on a substrate (eg, PCB). According to one embodiment, the antenna module 997 may include a plurality of antennas (eg, an array antenna). In this case, at least one antenna suitable for the communication method used in the communication network, such as the first network 998 or the second network 999, is connected to the plurality of antennas by, for example, the communication module 990. can be selected. Signals or power may be transmitted or received between the communication module 990 and an external electronic device through the selected at least one antenna. According to some embodiments, in addition to the radiator, other components (eg, radio frequency integrated circuit (RFIC)) may be additionally formed as part of the antenna module 997.

According to various embodiments, antenna module 997 may form a mmWave antenna module. According to one embodiment, a mmWave antenna module includes: a printed circuit board, an RFIC disposed on or adjacent to a first side (e.g., bottom side) of the printed circuit board and capable of supporting a designated high frequency band (e.g., mmWave band); And a plurality of antennas (e.g., array antennas) disposed on or adjacent to the second side (e.g., top or side) of the printed circuit board and capable of transmitting or receiving signals in the designated high frequency band. can do.

At least some of the components are connected to each other through a communication method between peripheral devices (e.g., bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)) and signal ( (e.g. commands or data) can be exchanged with each other.

According to one embodiment, commands or data may be transmitted or received between the electronic device 901 and the external electronic device 904 through the server 908 connected to the second network 999. Each of the external electronic devices 902 or 904 may be of the same or different type as the electronic device 901. According to one embodiment, all or part of the operations performed in the electronic device 901 may be executed in one or more of the external electronic devices 902, 904, or 908. For example, when the electronic device 901 must perform a function or service automatically or in response to a request from a user or another device, the electronic device 901 may perform the function or service instead of executing the function or service on its own. Alternatively, or additionally, one or more external electronic devices may be requested to perform at least part of the function or service. One or more external electronic devices that have received the request may execute at least part of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device 901. The electronic device 901 may process the result as is or additionally and provide it as at least part of a response to the request. For this purpose, for example, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology can be used. The electronic device 901 may provide an ultra-low latency service using, for example, distributed computing or mobile edge computing. In another embodiment, the external electronic device 904 may include an Internet of Things (IoT) device. Server 908 may be an intelligent server using machine learning and/or neural networks. According to one embodiment, the external electronic device 904 or server 908 may be included in the second network 999. The electronic device 901 may be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

Figure 10 is a block diagram 1000 illustrating a program 940 according to various embodiments. According to one embodiment, the program 940 includes an operating system 942, middleware 944, or an application 946 executable on the operating system 942 for controlling one or more resources of the electronic device 901. It can be included. Operating system 942 may include, for example, Android™, iOS™, Windows™, Symbian™, Tizen™, or Bada™. At least some of the programs 940 are preloaded into the electronic device 901, for example, at the time of manufacture, or are stored in an external electronic device (e.g., an electronic device 902 or 904, or a server) when used by a user. It can be downloaded or updated from 908)).

The operating system 942 may control management (e.g., allocation or recovery) of one or more system resources (e.g., process, memory, or power) of the electronic device 901. Operating system 942 may additionally or alternatively operate on other hardware devices of electronic device 901, such as input module 950, audio output module 955, display module 960, audio module 970. , sensor module 976, interface 977, haptic module 979, camera module 980, power management module 988, battery 989, communication module 990, subscriber identification module 996, or It may include one or more driver programs for driving the antenna module 997.

The middleware 944 may provide various functions to the application 946 so that functions or information provided from one or more resources of the electronic device 901 can be used by the application 946. The middleware 944 includes, for example, an application manager 1001, a window manager 1003, a multimedia manager 1005, a resource manager 1007, a power manager 1009, a database manager 1011, and a package manager 1013. ), connectivity manager (1015), notification manager (1017), location manager (1019), graphics manager (1021), security manager (1023), call manager (1025), or voice recognition manager (1027). You can.

The application manager 1001 may manage the life cycle of the application 946, for example. The window manager 1003 may, for example, manage one or more GUI resources used on the screen. For example, the multimedia manager 1005 identifies one or more formats required for playing media files, and encodes or decodes the corresponding media file using a codec suitable for the selected format. It can be done. The resource manager 1007 may, for example, manage the source code of the application 946 or the memory space of the memory 930. The power manager 1009 manages, for example, the capacity, temperature, or power of the battery 989, and can use this information to determine or provide related information necessary for the operation of the electronic device 901. . According to one embodiment, the power manager 1009 may interface with a basic input/output system (BIOS) (not shown) of the electronic device 901.

Database manager 1011 may create, search, or change a database to be used by application 946, for example. The package manager 1013 can, for example, manage the installation or update of applications distributed in the form of package files. The connectivity manager 1015 may manage, for example, a wireless connection or direct connection between the electronic device 901 and an external electronic device. For example, the notification manager 1017 may provide a function for notifying the user of the occurrence of a designated event (eg, an incoming call, message, or alarm). The location manager 1019 may, for example, manage location information of the electronic device 901. The graphics manager 1021 may, for example, manage one or more graphic effects to be provided to the user or a user interface related thereto.

Security manager 1023 may provide, for example, system security or user authentication. The telephony manager 1025 may manage, for example, a voice call function or a video call function provided by the electronic device 901. For example, the voice recognition manager 1027 transmits the user's voice data to the server 908 and provides a command corresponding to a function to be performed in the electronic device 901 based at least in part on the voice data, Alternatively, text data converted based at least in part on the voice data may be received from the server 908. According to one embodiment, the middleware 1044 may dynamically delete some existing components or add new components. According to one embodiment, at least a portion of the middleware 944 may be included as part of the operating system 942 or may be implemented as separate software different from the operating system 942.

Applications 946 include, for example, home 1051, dialer 1053, SMS/MMS (1055), instant message (IM) 1057, browser 1059, camera 1061, and alarm 1063. , Contacts (1065), Voice Recognition (1067), Email (1069), Calendar (1071), Media Player (1073), Album (1075), Watch (1077), Health (1079) (such as exercise amount or blood sugar) It may include applications that measure biometric information) or environmental information 1081 (e.g., measure atmospheric pressure, humidity, or temperature information). According to one embodiment, the application 946 may further include an information exchange application (not shown) that can support information exchange between the electronic device 901 and an external electronic device. The information exchange application may include, for example, a notification relay application configured to deliver designated information (e.g., calls, messages, or alarms) to an external electronic device, or a device management application configured to manage the external electronic device. there is. For example, the notification relay application transmits notification information corresponding to a specified event (e.g., mail reception) generated in another application (e.g., email application 1069) of the electronic device 901 to an external electronic device. You can. Additionally or alternatively, the notification relay application may receive notification information from an external electronic device and provide it to the user of the electronic device 901.

The device management application, for example, controls the power (e.g., turn-on or turn-off) of an external electronic device or some component thereof (e.g., a display module or camera module of the external electronic device) that communicates with the electronic device 901. ) or functions (such as brightness, resolution, or focus). A device management application may additionally or alternatively support installation, deletion, or update of applications running on external electronic devices.

Electronic devices according to various embodiments disclosed in this document may be of various types. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to embodiments of this document are not limited to the above-described devices.

The various embodiments of this document and the terms used herein are not intended to limit the technical features described in this document to specific embodiments, and should be understood to include various changes, equivalents, or replacements of the embodiments. In connection with the description of the drawings, similar reference numbers may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the above items, unless the relevant context clearly indicates otherwise. As used herein, “A or B”, “at least one of A and B”, “at least one of A or B”, “A, B or C”, “at least one of A, B and C”, and “A Each of phrases such as “at least one of , B, or C” may include any one of the items listed together in the corresponding phrase, or any possible combination thereof. Terms such as "first", "second", or "first" or "second" may be used simply to distinguish one component from another, and to refer to that component in other respects (e.g., importance or order) is not limited. One (e.g., first) component is said to be “coupled” or “connected” to another (e.g., second) component, with or without the terms “functionally” or “communicatively.” When mentioned, it means that any of the components can be connected to the other components directly (e.g. wired), wirelessly, or through a third component.

The term “module” used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and is interchangeable with terms such as logic, logic block, component, or circuit, for example. It can be used as A module may be an integrated part or a minimum unit of the parts or a part thereof that performs one or more functions. For example, according to one embodiment, the module may be implemented in the form of an application-specific integrated circuit (ASIC).

Various embodiments of the present document are one or more instructions stored in a storage medium (e.g., built-in memory 936 or external memory 938) that can be read by a machine (e.g., electronic device 901). It may be implemented as software (e.g., program 940) including these. For example, a processor (e.g., processor 920) of a device (e.g., electronic device 901) may call at least one command among one or more commands stored from a storage medium and execute it. This allows the device to be operated to perform at least one function according to the at least one instruction called. The one or more instructions may include code generated by a compiler or code that can be executed by an interpreter. A storage medium that can be read by a device may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' only means that the storage medium is a tangible device and does not contain signals (e.g. electromagnetic waves), and this term refers to cases where data is semi-permanently stored in the storage medium. There is no distinction between temporary storage cases.

According to one embodiment, methods according to various embodiments disclosed in this document may be included and provided in a computer program product. Computer program products are commodities and can be traded between sellers and buyers. The computer program product may be distributed in the form of a machine-readable storage medium (e.g. compact disc read only memory (CD-ROM)) or through an application store (e.g. Play Store™) or on two user devices (e.g. It can be distributed (e.g. downloaded or uploaded) directly between smart phones) or online. In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

According to various embodiments, each component (e.g., module or program) of the above-described components may include a single or plural entity, and some of the plurality of entities may be separately placed in other components. there is. According to various embodiments, one or more of the components or operations described above may be omitted, or one or more other components or operations may be added. Alternatively or additionally, multiple components (eg, modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each component of the plurality of components in the same or similar manner as those performed by the corresponding component of the plurality of components prior to the integration. . According to various embodiments, operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, or omitted. Alternatively, one or more other operations may be added.

Claims (20)

In electronic devices,
a memory including a first area in which a first version of an operating system (OS) is installed, a second area different from the first area, and a security area in which version information of the OS is stored; and
Includes a processor,
When the memory is executed by the processor, the processor:
Store update data corresponding to a second version of the OS in the second area,
Setting a part of the second area and a part of the first area where the update data is stored as a virtual partition,
Attempt to boot using the second version of the OS installed in the virtual partition,
Transfer the result of the booting to the security area,
An electronic device that stores instructions for determining whether to change the version information stored in the security area based on the results. According to claim 1,
When the instructions are executed by the processor, the processor
An electronic device that prevents the OS from being rolled back to a version older than the version information stored in the security area. According to claim 2,
When the instructions are executed by the processor, the processor
If the result indicates success, change the version information from the first version to the second version. According to claim 3,
When the instructions are executed by the processor, the processor
After changing the version information, the electronic device updates the OS of the first area to the second version of the OS by recording the update data in a portion corresponding to the update data among the OS data of the first area. According to claim 2,
When the instructions are executed by the processor, the processor
If the result indicates a failure, keep the version information as the first version,
An electronic device that attempts to boot using the first version of the OS stored in the first area. According to claim 1,
The security area is operated based on a security OS that is different from the OS. According to claim 6,
When the instructions are executed by the processor, the processor
An electronic device that uses a program on the secure OS to change or maintain the version information stored in the secure area based on the results. According to claim 1,
The first area and the second area are memory areas within a Rich Execution Environment (REE), and the security area is a memory area within a Trusted Execution Environment (TEE). In a method for updating an electronic device including memory and processor,
setting a part of the data area of the first version of the OS installed in the first area of the memory and the data area of the second version of the update data stored in the second area of the memory as a virtual partition;
Attempting to boot using the second version of the OS installed in the virtual partition;
An operation of transferring the result of the booting to a secure area of the memory; and
A method comprising determining whether to change the version information of the OS stored in the security area based on the results. According to clause 9,
The processor is set to prevent the OS from being rolled back to a version older than the version information stored in the security area. According to claim 12,
The operation of determining whether to change the version information includes, if the result indicates success, changing the version information from the first version to the second version. According to claim 11,
After changing the version information, updating the OS of the first area to the second version of the OS by recording the update data in a portion corresponding to the update data among the data of the OS of the first area. How to. According to claim 10,
The operation of determining whether to change the version information is,
If the result indicates failure, maintaining the version information as the first version; and
A method comprising attempting to boot using the first version of the OS stored in the first area. According to clause 9,
The method wherein the security area is operated based on a security OS different from the OS. According to claim 14,
The operation of determining whether to change the version information includes the operation of changing or maintaining the version information stored in the secure area based on the result using a program on the secure OS. According to clause 9,
The first area and the second area are memory areas within a Rich Execution Environment (REE), and the security area is a memory area within a Trusted Execution Environment (TEE). A computer-readable storage medium storing instructions executable by a processor, wherein the instructions, when executed, cause the processor to:
Setting a part of the data area of the first version of the OS installed in the first area of the memory and the data area of the second version of the update data stored in the second area of the memory as a virtual partition;
Attempting to boot using the second version of the OS installed in the virtual partition; and
An operation of transferring the result of the booting to a secure area of the memory; and
A computer-readable storage medium that performs an operation of determining whether to change the version information of the OS stored in the security area based on the result. According to claim 17,
When the instructions are executed, the processor prevents the OS from being rolled back to a version older than the version information stored in the security area. According to claim 18,
wherein the instructions, when executed, cause the processor to change the version information from the first version to the second version if the result indicates success. According to claim 19,
When the instructions are executed, the processor, after changing the version information, records the update data in a portion corresponding to the update data among the data of the OS of the first area, thereby converting the OS of the first area to the second area. A computer-readable storage medium that allows updating to the current version of the OS.

Images