Memory device with secure boot update and automatic recovery

Abstract

The present disclosure relates to a memory device with secure boot update and automatic recovery. Example embodiments relate to improvements in managing boot code images. In embodiments, a device is disclosed that includes a memory device including a storage array comprising a first partition and a second partition, wherein the first partition comprises a writable partition and the second partition comprises a write-protected partition; and a processor configured to: load a golden boot image from the second partition; display a boot prompt after loading the golden boot image; receive an update boot image, the update boot image including a signature; read a public key from the second partition; verify the signature using the public key; and replace a current boot image stored in the first partition with the update boot image.

Description

Technical Field

[0001] The example embodiments relate to memory devices, and more specifically, to techniques for managing boot images. Background Technology

[0002] Currently, memory devices such as embedded multimedia card (eMMC) devices allow users to update the boot code image via a boot prompt. However, such systems do not support any type of verification for replacing the boot code image. Therefore, the boot code image (especially a remote source image) can be tampered with before installation. If the active boot image is corrupted, all future updates cannot be trusted because the boot code that manages the updates is itself corrupted. Summary of the Invention

[0003] In one aspect, this disclosure relates to an apparatus comprising: a memory device including a storage array including a first partition and a second partition, wherein the first partition includes a writable partition and the second partition includes a write-protected partition; and a processor configured to: load a gold boot image from the second partition; display a boot prompt after loading the gold boot image; receive an updated boot image containing a signature; read a public key from the second partition; verify the signature using the public key; and replace a current boot image stored in the first partition with the updated boot image.

[0004] In another aspect, this disclosure relates to a method comprising: loading a gold boot image from a write-protected partition of a storage array contained in a memory device; displaying a boot prompt after loading the gold boot image; receiving an updated boot image, the updated boot image containing a signature; reading a public key from the write-protected partition; verifying the signature using the public key; and replacing a current boot image stored in a writable partition of the storage array with the updated boot image.

[0005] In another aspect, this disclosure relates to a non-transitory computer-readable storage medium for tangibly storing computer program instructions executable by a computer processor, the computer program instructions defining the steps of: loading a gold boot image from a write-protected partition of a storage array contained in a memory device; displaying a boot prompt after loading the gold boot image; receiving an updated boot image containing a signature; reading a public key from the write-protected partition; verifying the signature using the public key; and replacing a current boot image stored in a writable partition of the storage array with the updated boot image. Attached Figure Description

[0006] Figure 1This is a block diagram illustrating a memory device according to some example embodiments.

[0007] Figure 2 This is a flowchart illustrating a method for initializing a memory array for a memory device according to some example embodiments.

[0008] Figure 3 This is a flowchart illustrating a method for initializing startup code updates for a memory device according to some example embodiments.

[0009] Figure 4 This is a flowchart illustrating a method for updating startup code of a memory device according to some example embodiments.

[0010] Figure 5 This is a flowchart illustrating a method for verifying startup code updates in a memory device, according to some example embodiments.

[0011] Figure 6 This is a block diagram illustrating a computing system according to some example embodiments.

[0012] Figure 7 This is a block diagram illustrating a computing device according to some example embodiments. Detailed Implementation

[0013] In the various example embodiments provided below, techniques for securely updating a boot image are provided. Storage media (e.g., a memory device) is configured with a write-protected area for storing the golden boot image and a public key. A second writable area stores the active boot loader. In response to entering secure boot mode (e.g., via a key press during startup), the user can switch to using the golden boot loader and continue attempting to replace the active boot loader with an updated boot loader. The golden boot code is configured to verify any requested update image using a tamper-proof public key and version number constraints. If constraint or key verification fails, the example embodiments support rolling back the update process and restoring to the current boot scheme.

[0014] Figure 1 This is a block diagram illustrating a memory device according to some example embodiments.

[0015] In the illustrated embodiment, memory device 100 may include a controller 114 and a storage region 102. Storage region 102 may include a writable partition 104 (also referred to as a "first partition") and a write-protected partition 108 (also referred to as a "second partition"). As illustrated, writable partition 104 may contain a signed boot image 106. Similarly, write-protected partition 108 may contain a golden boot image 110 and a server public key 112. In some embodiments, memory device 100 may include an eMMC device.

[0016] In the illustrated embodiments, controller 114 may include a microcontroller, microprocessor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or similar processing element. In some embodiments, controller 114 may perform various operations to access data stored in storage area 102. In some embodiments, controller 114 may communicate with a host processor (not shown) and provide data stored in storage area 102 to the host processor. Figure 5 The details of communication between the host processor and memory device 100 are provided. As an example, storage area 102 may contain components for booting the computer system (e.g., ...). Figure 6 The boot code image is a graphical representation of the system. As used herein, a boot code image refers to a software image that runs during operation on the computing system. In some embodiments, the boot code image may contain a boot loader or similar early code. In some embodiments, the boot code image may contain a secure boot loader, such as Das U-boot, created and maintained by DENX Software Engineering GmbH in Upper Bavaria, Germany. Other boot loading technologies may be used.

[0017] In the illustrated embodiment, storage area 102 is divided into two partitions: a writable partition 104 and a write-protected partition 108. Storage area 102 may be divided into more partitions (not described) and there is no limitation on the number or characteristics of additional partitions.

[0018] In the illustrated embodiments, writable partition 104 may contain writable partitions. As used herein, a writable partition refers to a partition that can be written to (or read from) by a non-privileged user. In some embodiments, a non-privileged user may include any user, while in some embodiments, a non-privileged user may include only a subset of users (e.g., users of the operating system with root privileges). Conversely, write-protected partition 108 includes a write-protected area. In some embodiments, the write-protected area includes a memory area that can be written to only by privileged users. In some embodiments, all users can read data from write-protected partition 108. As used herein, a privileged user refers to a user who has write permissions to write-protected partition 108. Specifically, in embodiments, a privileged user may include a user who can access the private key corresponding to the server public key 112. For example, a privileged user may include the manufacturer of the memory device 100. Figure 2 The general argues that manufacturers can manually designate write-protected partition 108 as write-protected during manufacturing via physical jumpers or similar structures. In other embodiments, write protection can be enabled programmatically.

[0019] Before setting write-protected partition 108 to write-protected, the manufacturer can write the gold boot image 110 and the server public key 112 to write-protected partition 108. In the illustrated embodiment, the gold boot image 110 may contain a secure base boot image. In some embodiments, the gold boot image 110 may contain a boot image that implements basic or standard system initialization routines (e.g., network and memory access) and security update commands (described in more detail herein). Therefore, the gold boot image 110 provides the minimum functionality to bring the system online and is not easily damaged or attacked.

[0020] Write protection partition 108 additionally stores the server public key 112. In embodiments, the server public key 112 may contain the public key portion of an asymmetric key pair. Various asymmetric key generation algorithms, such as Rivest-Shamir-Adleman (RSA) or Elliptic Curve Cryptography (ECC), can be used to generate the key pair, and this disclosure does not limit the specific algorithm used. In embodiments, the manufacturer of the memory device 100 generates the asymmetric key pair during device manufacturing and writes the server public key portion of the key pair to the write protection partition 108 before enabling write protection for the write protection partition 108. Furthermore, the manufacturer may write the gold boot image 110 to the write protection partition 108 before enabling write protection. After writing the gold boot image 110 and the server public key 112, the manufacturer may enable write protection to protect the data written to the write protection partition 108. As discussed, in some embodiments, this data may not be static and immutable throughout the lifetime of the memory device 100. In other embodiments, only the holder of the private key corresponding to the server public key 112 may be able to write to the write protection partition 108. In this embodiment, the holder of the private key can issue a signing command to the controller 114, which temporarily disables write protection for the write-protected partition 108 and allows updates to the gold boot image 110, the server public key 112, or other data stored in the write-protected partition 108. After the update is completed, the holder of the private key can sign a command to re-enable write protection and issue this command to the controller 114 to re-enable protection for the write-protected partition 108. In some embodiments, the write-protected partition 108 may contain multiple write-protected partitions, and the gold boot image 110 can be written to one write-protected partition while the server public key 112 can be written to different write-protected partitions.

[0021] Compared to write-protected partition 108, writable partition 104 can be freely written to by any party other than the holder of the private key corresponding to server public key 112. For example, a user can manually update the signed boot image 106 during operation of storage device 100. In some embodiments, the computing system can be configured to boot directly from the signed boot image 106 by default, thereby allowing users to boot from their own boot code (compared to the golden boot image 110). However, it is worth noting that in some embodiments, the system may require the signed boot image 106 to be signed with the private key corresponding to server public key 112. That is, although the signed boot image 106 can be written to by any user, the holder of the private key corresponding to server public key 112 must still be the deliverer of the signed boot image 106.

[0022] The following flowchart describes the various details of starting up the computing system equipped with memory device 100.

[0023] Figure 2 This is a flowchart illustrating a method 200 for initializing a memory array for a memory device according to some example embodiments. In some embodiments, method 200 may be performed by a manufacturer during the manufacture of the memory device (e.g., memory device 100). That is, the manufacturer may perform method 200 in a secure manufacturing facility while all storage locations of memory device 100 are available for writing.

[0024] In block 202, method 200 may include writing the latest boot image to a first partition. In an embodiment, the first partition may contain... Figure 1 The writable partition 104. In embodiments, the latest boot image may contain any boot image (e.g., a secure boot image) that is desired as the default boot image for the storage device storing the first partition. In some embodiments, the latest boot image may contain a gold boot image; however, in most embodiments, the latest boot image will include a more fully functional boot image. Generally, any image including a boot loader or similar boot image can be used. In some embodiments, the latest boot image may be signed by an operator of method 200 (e.g., a manufacturer) using a private key (corresponding to the server public key, as discussed below).

[0025] In box 204, method 200 may include writing the gold boot image and server public key to a second partition. In an embodiment, the first partition may contain... Figure 1 The write-protected partition 108. In one embodiment, the gold boot image may contain, as shown below: Figure 1The golden boot image 110 is discussed in the text. Simply put, the golden boot image may contain a boot loader image that reduces the complexity of system initialization, and a hint or other interface that allows updating the boot loader code of the computing device. Additionally, method 200 may write the server public key to the second partition. As mentioned above... Figure 1 As discussed in the text, the server public key may contain the public key portion of an asymmetric key pair (e.g., an RSA or ECC key pair) generated by an operator of method 200 (e.g., during manufacturing). As in box 202, in some embodiments, box 204 may contain signing the gold boot image with a private key corresponding to the server public key.

[0026] In block 206, method 200 may include setting the boot partition as the first partition. As used herein, the boot partition refers to the designated partition that is accessed first when the device starts. Generally, a computing system will request data stored starting from a first location in the boot partition to load and execute the boot image. In block 206, method 200 sets the first partition (containing the latest boot image) as the boot partition. Therefore, when a computing device using the memory device operating in method 200 starts, it will request the latest boot image during startup. Figure 3 Details of this startup are provided in the description.

[0027] In box 208, method 200 may include marking the second partition as write-protected. For example... Figure 1 As discussed, the entire memory array of the memory device can be writable during manufacturing. Therefore, after performing block 204 in method 200, method 200 can set the second partition to read-only (i.e., write-protected). In some embodiments, block 208 may include physically altering the memory device to enable write protection (e.g., changing jumpers or fuses), or may include instructing the controller of the memory device to prevent writes to one or more locations or partitions. In some embodiments, method 200 may include writing the gold boot image and server public key to one-time programmable (OTP) memory, and therefore block 208 may be omitted in this embodiment. However, when using write protection for standard memory partitions implemented by a controller, method 200 can programmatically enable and disable write protection (e.g., based on commands signed with a private key corresponding to the server public key), which allows for secure updates to the gold boot image and server public key.

[0028] Once method 200 is completed, the memory device containing the first and second partitions can be released from manufacturing and provided to the end user or customer. As discussed, the memory device can be installed in a computing system and used as the system's storage device (e.g., eMMC). Therefore, when the computing system boots up, the computing system accesses the memory device and attempts to load a boot image. Since the first partition is set as the boot partition, any such computing device will load the currently installed boot image in the first partition. Upon first power-on, this latest currently installed boot image will include the latest boot image as specified by the manufacturer. However, as will be discussed, the currently installed boot image may include a different boot loader updated after the memory device is released from manufacturing.

[0029] Figure 3 This is a flowchart illustrating a method 300 for initializing a startup code update for a memory device according to some example embodiments. In some embodiments, method 300 may be executed by a computing system equipped with memory device 100.

[0030] In block 302, method 300 may include powering on the computing system. In some embodiments, block 302 may further include powering on the memory device 100 and other components of the computing system.

[0031] In block 304, method 300 may include determining whether a predefined key has been input. In some embodiments, method 300 may monitor any key. In an embodiment, method 300 may monitor the input of a specific key (e.g., the exit key).

[0032] In block 306, method 300 may include booting to the latest boot image when no key is detected. In one embodiment, method 300 may execute block 306 by reading the boot image from a memory device at a first bootable location. In an embodiment, this first bootable location may include... Figure 2 The first partition is described in the text. In response to a request for a boot image, the memory device returns the latest boot image stored in the first partition, and the computing system can load the boot image into memory and execute the latest boot image.

[0033] In block 322, if method 300 does not detect a key press in block 306, method 300 continues with normal startup. In an embodiment, method 300 may execute the latest boot image and initialize the system, then pass control to a second-level boot loader to continue startup. In some embodiments, the latest boot image may pass control directly to the operating system (OS). In some embodiments, multiple boot loaders may be executed sequentially, and the specific arrangement of boot loaders and the OS is not limiting. As illustrated, method 300 terminates after it continues to boot to the OS. After method 300 terminates, the computing system is fully booted.

[0034] If method 300 detects a key press in block 304, method 300 may display a boot prompt using the latest boot code in block 308. The latest boot code refers to an executed copy of the latest boot image read from the first partition. In one embodiment, the boot prompt may include a terminal-based interface. In other embodiments, the boot prompt may include a graphical user interface (GUI). In any embodiment, the boot prompt allows the user to input a boot command. In one embodiment, the available boot commands may include a switching command. The switching command may allow switching between the latest boot image and the golden boot image. Specifically, the switching command may allow changing the boot partition from the first partition to the second partition. Of course, other boot commands may be issued via the boot prompt. This disclosure is not limited to switching commands only.

[0035] In box 310, method 300 may include receiving a startup command. The startup command may include a toggle command or other commands. This disclosure does not describe such other commands in detail, nor does it limit the types of other commands.

[0036] In one embodiment, the switching command may comprise a single command. In other embodiments, the switching command may comprise a series of commands executed in a specific order. For example, the switching command may be implemented using existing startup code commands, such as:

[0037] mmc partconf 0 1 2 1

[0038] mmc bootbus 0 1 0 0

[0039] In the above example, the switching command is implemented as two calls to the mmc command in the Das U-Boot bootloader. The first mmc command executes the subcommand partconf, which changes the configuration of the memory device's partition mapping to use the second (2) partition. The second mmc command executes the bootbus subcommand, which configures the boot bus width. In this embodiment, the command continues in a power loop until the change is made. Further details can be found in the documentation for the mmc command in Das U-Boot. When implemented as a single command, the switching command can be configured as a shell script to simulate the execution of a single native command.

[0040] In box 312, method 300 determines what type of command was received. If the command is not a toggle command, method 300 proceeds to box 314 and executes the command based on the latest startup code image. Details of the normal execution of startup commands are not provided in this document.

[0041] If method 300 determines that a switch command is entered in box 312, method 300 proceeds to box 316, whereby the method switches the boot partition to the second partition. As described above, box 316 may include executing a switch command (e.g., two mmc commands) entered via a prompt. Continuing with the previous example, the partconf subcommand, when executed, can cause a switch of the boot partition. In other embodiments, a single switch command, when executed, can cause a switch of the boot partition.

[0042] In block 318, method 300 performs power cycling on the device. In some embodiments, a user can manually initiate power cycling by issuing a reset command, for example, via a startup prompt. In other embodiments, the switching command itself can automatically perform power cycling on the computing system.

[0043] After the power cycle, method 300 then enables the safety update process in block 320. Figure 4 Further details of this process are provided below. Once the update process is complete, method 300 can terminate.

[0044] Figure 4 This is a flowchart illustrating a method 400 for updating boot code of a memory device according to some example embodiments.

[0045] In block 402, method 400 may include powering on the computing system. In some embodiments, block 402 may further include powering on the memory device 100 and other components of the computing system. In the illustrated embodiments, as in Figure 3 As described in blocks 316 and 318, method 400 executes block 402 after changing the boot partition of the memory device and performing a power cycle on the computing system.

[0046] In block 404, method 400 may include reading and loading the gold boot code image. In an embodiment, the gold boot code image is stored on a second partition, and therefore when method 400 starts, it automatically reads and executes the gold boot code image.

[0047] In block 406, method 400 may include determining whether a predefined key has been input. In some embodiments, method 400 may monitor any key. In an embodiment, method 400 may monitor the input of a specific key (e.g., the exit key).

[0048] If method 400 does not detect a key press, method 400 may then boot from the first partition in block 420. In an embodiment, the gold boot code image is configured to automatically transfer control to any boot loader stored in the first partition. Therefore, if method 400 does not detect a key press, method 400 may include automatically booting to the first partition. In one embodiment, as part of block 404, the gold boot code image may verify a signature associated with the boot code image stored in the first partition. In some embodiments, method 400 may verify the signature using a server public key stored in a second partition. If method 400 cannot verify the signature, method 400 may abort and display an error. In other embodiments, if method 400 cannot verify the signature, method 400 may then proceed to block 408 instead of aborting.

[0049] If method 400 detects a key press, method 400 may display a boot prompt provided by the Golden Boot Code, which runs from the Golden Boot Code image. In some embodiments, the Golden Boot Code includes a security update command that implements a secure boot code update (in... Figure 5 (As described in more detail below). In other respects, a startup tip can be substantially similar to a startup tip associated with the latest startup code (e.g., the Das U-Boot tip).

[0050] In box 410, method 400 may include receiving a startup command. The startup command may include a security update command or other commands. The security update command may allow updating the latest startup code to a new version and verifying the new version. This disclosure does not detail such other commands and does not limit the types of other commands.

[0051] In one embodiment, the security update command allows the user to specify a new boot image. The computing system can then use this new boot image to update the latest boot image to the new boot image. In another embodiment, the security update command includes a termination command. In yet another embodiment, the security update command accepts a local filename as an argument (e.g., a locally stored boot image) or a remote address of the boot image. If the user provides a remote address, the security update command can load the remote boot image via a network protocol. In another embodiment, the network protocol may include the Simple File Transfer Protocol (TFTP). In some embodiments, the security update command may accept the same update command as a standard update command (e.g., the update command in the Das U-Boot system).

[0052] In box 412, method 400 determines what type of command was received. If the command is not a security update command, method 400 proceeds to box 414 and executes the command based on the gold startup code image. Details of the normal execution of the startup command are not provided in this document.

[0053] If method 400 determines that a security update command has been entered in box 412, then method 400 proceeds to box 416, where it verifies and writes the new boot image. Details of this process are... Figure 5 As described in the text and will not be repeated here.

[0054] Once method 400 verifies the requested updated boot code image, method 400 may switch the boot partition to the first partition containing the updated boot code image in block 418. In one embodiment, the switch command ( Figure 3 (As described in the text) or a sequence of commands can be used to switch the boot partition in box 418. In some embodiments, the use of the switch command is executable as part of an update command. In other embodiments, the user can manually enter the switch command.

[0055] In block 422, method 400 performs a power cycle on the device. In some embodiments, a user may manually initiate the power cycle by issuing a reset command, for example, via a startup prompt. In other embodiments, a security update command itself may automatically perform a power cycle on the computing system. After the power cycle, method 400 may terminate. In some embodiments, upon restart, the computing system may execute method 300 as a regular startup routine, thus enabling on-demand entry into method 400.

[0056] Figure 5 This is a flowchart illustrating a method 500 for verifying startup code updates in a memory device according to some example embodiments.

[0057] In block 502, method 500 may include receiving a signed updated image and a version number. In embodiments, the signed updated image may be read locally from a storage device or retrieved from a remote location. In embodiments, the signed updated image is associated with a digital signature. In embodiments, this digital signature may be generated using a server's private key or other remote computing device. In embodiments, the storage device contains a corresponding public key stored in a write-protected area of ​​the storage device. In embodiments, the signature may be computed by hashing the updated image and using the hash to compute the signature. In embodiments, the signature may be generated by concatenating the hash with the version number and computed on the concatenation. In embodiments, the version number includes a number conforming to a pre-configured version numbering scheme. For example, a semantic versioning scheme may be used. Alternatively, the version numbering scheme may include an incrementing version number.

[0058] In block 504, method 500 may include reading the current version number of the latest boot code image stored in the first partition. In one embodiment, the current version number may be stored in a pre-configured location of the boot code image (e.g., a specific byte offset of the boot code image). In another embodiment, the current version may be maintained in a separate location (e.g., a configuration register or other location).

[0059] In box 506, method 500 may include determining whether a version number received in box 502 is valid, given the current version number read in box 504. In an embodiment, method 500 may perform box 506 by determining whether the current version number is less than the version number received in box 502. Other techniques may be used. For example, the version number may include an irreversible hash of a previous version. Therefore, in this embodiment, method 500 may compute a hash of the current version and determine whether the hash is equal to the version number received in box 502. Other schemes (e.g., semantic version comparison) may be used.

[0060] If method 500 determines that the version number received in block 502 is invalid, method 500 may abort the update in block 508. In one embodiment, method 500 may abort by displaying an error message and returning to the boot prompt or by forcing a cold restart. In some embodiments, method 500 may reset the boot partition to the first partition to "reset" the boot state to the default latest boot code image. In other embodiments, method 500 may maintain the current boot priority to boot again from the second partition after a reboot.

[0061] However, if method 500 determines that the version number received in box 502 is valid, method 500 may then read the server public key from the second partition in box 510. As discussed, the second partition may include a write-protected partition, and therefore method 500 may assume that the server public key is secure and has not been tampered with.

[0062] In box 512, method 500 can use the server public key read in box 510 to verify the signature received in box 502. In one embodiment, method 500 can calculate the hash of the updated image, then decrypt the signature using the public key and compare the decryption result with a locally generated hash to verify the digital signature.

[0063] In box 514, method 500 may determine whether the signature is valid. If not, method 500 may abort the update in box 508. In one embodiment, method 500 may abort by displaying an error message and returning to the boot prompt or by forcing a cold restart. In some embodiments, method 500 may reset the boot partition to the first partition to "reset" the boot state to the default latest boot code image. In other embodiments, method 500 may maintain the current boot priority to boot again from the second partition after a reboot.

[0064] However, if method 500 confirms the digital signature is valid, the method may replace the latest boot code image with the updated image received in box 502 in box 516. In an embodiment, method 500 may erase the current latest boot code image from the first partition and then write the updated image to the first partition. Figure 4 As discussed in the text, after executing box 516, the computing system can change the boot partition (box 418) and restart (box 422). Therefore, the security update image is then used for booting.

[0065] Figure 6 This is a block diagram illustrating a computing system according to some example embodiments.

[0066] like Figure 6 As described, the system includes a host processor 620 communicatively coupled to a memory system 600 via a bus 604. The memory system 600 includes a controller 606 communicatively coupled to one or more memory banks 608 forming a memory array via a bus / interface 612. As described, the controller 606 includes a local cache 614, firmware 616, and error correction code (ECC) circuitry (e.g., an ECC module 618).

[0067] In the illustrated embodiments, the host processor 620 may include any type of computer processor, such as a central processing unit (CPU), a graphics processing unit (GPU), or other types of general-purpose or special-purpose computing devices. The host processor 620 includes one or more output ports that allow the transfer of address, user, and control data between the host processor 620 and the memory system 600. In the illustrated embodiments, this communication is performed via a bus 604. In one embodiment, the bus 604 includes an input / output (I / O) bus or a similar type of bus.

[0068] The memory system 600 manages one or more memory banks 608. In one embodiment, the one or more memory banks 608 include NAND flash dies or other configurations of non-volatile memory. In one embodiment, the one or more memory banks 608 include a memory array, such as a memory array.

[0069] Controller 606 manages one or more memory banks 608. In some embodiments, controller 606 includes a computing device configured to mediate access to and from the one or more memory banks 608. In one embodiment, controller 606 includes an ASIC or other circuitry mounted on a printed circuit board housing the one or more memory banks 608. In some embodiments, controller 606 may be physically decoupled from the one or more memory banks 608. Controller 606 communicates with the one or more memory banks 608 via interface 612. In some embodiments, this interface 612 includes a physically wired (e.g., traced) interface. In other embodiments, interface 612 includes a standard bus for communicating with the one or more memory banks 608.

[0070] The controller 606 includes various modules 614 to 618. In one embodiment, the various modules 614 to 618 include various physically different modules or circuits. In other embodiments, modules 614 to 618 may be implemented entirely (or partially) in software or firmware.

[0071] As explained, firmware 616 includes the core of the controller and manages all operations of controller 606. Firmware 616 may implement some or all of the methods described above. Specifically, firmware 616 may be implemented in Figures 2 to 5 The method described in [the document / document].

[0072] Figure 7 This is a block diagram illustrating a computing device according to some example embodiments.

[0073] The computing device 700 may contain more than Figure 7 The components shown may include more or fewer components. For example, a server computing device may not include an audio interface, display, keypad, lights, haptic interface, GPS receiver, camera, or sensors.

[0074] As shown in the figure, computing device 700 includes a processing unit (CPU 722) that communicates with mass storage 730 via bus 724. Computing device 700 also includes one or more network interfaces 750, an audio interface 752, a display 754, a keypad 756, a light source 758, an input / output interface 760, a haptic interface 762, an optional Global Positioning System (GPS) receiver, such as a GPS receiver 764, and a camera or other optical, thermal, or electromagnetic sensor (e.g., sensor 766). As those skilled in the art will understand, computing device 700 may include sensor 766. The positioning of sensor 766 on computing device 700 may vary depending on the model of computing device 700, the capabilities of computing device 700, or a combination thereof.

[0075] The computing device 700 may optionally communicate with a base station (not shown) or directly with another computing device. One or more network interfaces 750 are sometimes referred to as transceivers, transceiver devices, or network interface card (NIC) devices.

[0076] Audio interface 752 generates and receives audio signals, such as human speech. For example, audio interface 752 may be coupled to a speaker and microphone (not shown) to enable telecommunications with other people or to generate audio confirmation for certain actions. Display 754 may be a liquid crystal display (LCD), a gas plasma display, a light-emitting diode (LED), or any other type of display used with a computing device. Display 754 may also include a touch-sensitive screen arranged to receive input from an object such as a stylus or a finger from a human hand.

[0077] The keypad 756 may include any input device arranged to receive input from the user. The illuminator 758 may provide status indication or provide light.

[0078] The computing device 700 also includes a means for using, for example, USB, infrared, Bluetooth. TM The input / output interface 760 is for communication with external devices using communication technologies. The haptic interface 762 provides haptic feedback to the user of the client device.

[0079] GPS receiver 764 can determine the physical coordinates of computing device 700 on the Earth's surface, typically outputting the location as latitude and longitude values. GPS receiver 764 may also employ other geolocation mechanisms, including but not limited to triangulation, assisted GPS (AGPS), E-OTD, CI, SAI, ETA, BSS, etc., to further determine the physical location of computing device 700 on the Earth's surface. However, in one embodiment, computing device 700 may utilize other components to provide additional information that can be used to determine the device's physical location, including, for example, a MAC address, an Internet Protocol (IP) address, etc.

[0080] Mass storage 730 includes RAM 732, ROM 734, and other storage devices. Mass storage 730 illustrates another example of computer storage media used to store information such as computer-readable instructions, data structures, program modules, or other data. Mass storage 730 stores a basic input / output system, such as a BIOS 740, for controlling the low-level operation of computing device 700. Mass storage also stores an operating system 741 for controlling the operation of computing device 700.

[0081] Application 742 may include computer-executable instructions that, when executed by computing device 700, perform any of the methods (or portions thereof) previously described in the description of the preceding figures. In some embodiments, software or programs implementing method embodiments may be read from a hard disk drive (not shown) and temporarily stored in RAM 732 by CPU 722. CPU 722 may then read software or data from RAM 732, process the software or data, and store it back into RAM 732.

[0082] This disclosure includes various means for performing the methods and implementing the systems described above, including a data processing system for performing these methods, and a computer-readable medium containing instructions that, when executed on the data processing system, cause the system to perform the methods.

[0083] The descriptions and figures are illustrative and should not be construed as limiting. Numerous specific details are described to provide a thorough understanding. However, in some cases, well-known or conventional details have not been described to avoid obscuring the description. References to "one" or "a" embodiment in this disclosure do not necessarily refer to the same embodiment, and such references imply at least one.

[0084] References to "one embodiment" or "an embodiment" in this specification mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of this disclosure. The phrase "in one embodiment" appearing in various places throughout this specification does not necessarily refer to all of the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. Furthermore, various features that may be manifested by some embodiments but not by others are described. Similarly, various requirements are described, which may be requirements for some embodiments but not others.

[0085] In this description, various functions and operations may be described as being executed by or caused by software code for the sake of simplicity. However, those skilled in the art will recognize that these expressions mean that the functions are generated by the execution of code by one or more processors such as microprocessors, ASICs, graphics processors, or FPGAs. Alternatively or in combination, functions and operations may be implemented using dedicated circuit systems (e.g., logic circuit systems) with or without software instructions. Embodiments may be implemented using hardwired circuit systems without or in combination with software instructions. Therefore, the techniques described are neither limited to any particular combination of hardware circuit systems and software, nor to any particular source of instructions executed by a computing device.

[0086] While some embodiments may be implemented in fully functional computers and computer systems, various embodiments can be distributed as computing products in a variety of forms and are applicable regardless of the specific type of machine or computer-readable medium used to implement the distribution.

[0087] At least some of the disclosed aspects may be embodied, at least in part, in software. That is, the techniques may be performed in a computing device or other system in response to its processor (e.g., a microprocessor) executing a sequence of instructions contained in memory (e.g., ROM, volatile RAM, non-volatile memory, cache, or remote storage device).

[0088] The routines implemented to carry out the embodiments can be implemented as part of an operating system, middleware, business delivery platform, software development kit (SDK) components, network services, or other specific application, component, program, object, module, or sequence of instructions referred to as a "computer program." The calling interface of these routines can be exposed to the software development community as an application programming interface (API). Computer programs typically include one or more sets of instructions stored in various memories and storage devices within a computer at various times, and these sets of instructions, when read and executed by one or more processors in the computer, cause the computer to perform operations necessary for carrying out various aspects.

[0089] Machine-readable media can be used to store software and data that, when executed by a computing device, causes the device to perform various methods. Executable software and data can be stored in various locations, including, for example, ROM, volatile RAM, non-volatile memory, or cache. A portion of this software or data can be stored in any of these storage devices. Furthermore, data and instructions can be obtained from a centralized server or a peer-to-peer network. Different portions of data and instructions can be obtained from different centralized servers or peer-to-peer networks at different times and in different communication sessions or within the same communication session. All data and instructions can be obtained before the application is executed. Alternatively, portions of data and instructions can be obtained dynamically and as needed for execution. Therefore, it is not required that all data and instructions be on the machine-readable media at any given time.

[0090] Examples of computer-readable media include, but are not limited to, recordable and non-recordable media, such as volatile and non-volatile memory devices, read-only memory (ROM), random access memory (RAM), flash memory devices, solid-state drive storage media, removable disks, disk storage media, optical storage media (e.g., optical disc read-only memory (CDROM), digital versatile disc (DVD), etc.). Computer-readable media can store instructions.

[0091] Generally speaking, tangible or non-transitory machine-readable media includes any entity that provides (e.g., stores) information in a form accessible to a machine (e.g., a computer, mobile device, network device, personal digital assistant, manufacturing tool, any device having one or more processors, etc.).

[0092] In various embodiments, hardwired circuitry systems can be used in combination with software and firmware instructions to implement the technology. Therefore, the technology is neither limited to any particular combination of hardware circuitry systems and software, nor to any particular source of instructions executed by a computing device.

[0093] A wide variety of computing devices of different types can be used to implement the various embodiments described herein. As used herein, examples of “computing devices” include, but are not limited to, servers, centralized computing platforms, systems with multiple computing processors or mobile devices, user terminals, vehicles, personal communication devices, wearable digital devices, electronic self-service terminals, general-purpose computers, electronic document readers, tablet computers, laptop computers, smartphones, digital cameras, home appliances, televisions, or digital music players. Additional examples of computing devices include portions of devices referred to as “Internet of Things” (IoT). Such “things” may interact incidentally with their owners or administrators who may monitor or modify settings on these things. In some cases, such owners or administrators act as users of the “thing” devices. In some instances, a user’s primary mobile device (e.g., an Apple iPhone) may be an administrator server for paired “thing” devices worn by the user (e.g., an Apple Watch).

[0094] In some embodiments, the computing device may be a computer or a host system, such as a desktop computer, laptop computer, web server, mobile device, or another computing device including memory and processing means. The host system may include or be coupled to a memory subsystem, such that the host system can read data from or write data to the memory subsystem. The host system may be coupled to the memory subsystem via a physical host interface. Generally, the host system may access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0095] In some embodiments, the computing device is a system comprising one or more processing devices. Examples of processing devices may include a microcontroller, a central processing unit (CPU), a dedicated logic circuit system (e.g., an FPGA, an ASIC, etc.), a system-on-a-chip (SoC), or another suitable processor.

[0096] Although some figures illustrate multiple operations in a specific order, these operations can be reordered regardless of the order, and other operations can be combined or decomposed. While some reorderings or other groupings are specifically mentioned, other reorderings or groupings will be apparent to those skilled in the art, and therefore an exhaustive list of alternatives is not provided. Furthermore, it should be recognized that the described stages can be implemented in hardware, firmware, software, or any combination thereof.

[0097] In the foregoing description, this disclosure has been described with reference to specific exemplary embodiments of the invention. It will be apparent that various modifications may be made without departing from the broader spirit and scope set forth in the appended claims. Therefore, the description and drawings should be viewed in an illustrative rather than restrictive sense.

Claims

1. A computing device comprising: A memory device, the memory device comprising a memory array, the memory array including a first partition and a second partition, wherein the first partition includes a writable partition and the second partition includes a write-protected partition; and Processor, the processor being configured to: Load the gold boot image from the second partition. A startup prompt is displayed after the gold boot image is loaded. Receive an updated boot image, which contains a signature. Read the public key from the second partition. Verify the signature using the public key, and Replace the current boot image stored in the first partition with the updated boot image.

2. The computing device of claim 1, wherein the memory device includes an embedded multimedia card (eMMC) device.

3. The computing device of claim 1, wherein the processor is further configured to: Boot from the current boot image stored in the first partition; A second boot prompt is displayed in response to a key press detected while the current boot image is being executed; Receive the switching command via the second startup prompt; Set the second partition as the boot partition; and The starting device is reset.

4. The computing device of claim 1, wherein the signature is generated based on the contents of the updated boot image and the update version number.

5. The computing device of claim 1, wherein the processor is further configured to: Read the current version number associated with the current boot image; and Before replacing the current boot image, it is determined that the current version number is less than the update version number associated with the updated boot image.

6. The computing device of claim 1, wherein the processor is further configured to receive an update command via the startup prompt, the update command including a filename associated with the update startup image.

7. The computing device of claim 6, wherein the filename includes one of a local filename and a remote address.

8. The computing device of claim 1, wherein the processor is further configured to: After replacing the current boot image, the first partition is set as the boot partition; and The starting device is reset.

9. A method for a memory device, comprising: Load the gold boot image from the write-protected partition of the memory array contained in the memory device; A startup prompt is displayed after the gold boot image is loaded; Receive an updated boot image, the updated boot image containing a signature; Read the public key from the write-protected partition; Verify the signature using the public key; and Replace the current boot image stored in the writable partition of the storage array with the updated boot image.

10. The method of claim 9, wherein before loading the gold boot image, the method further comprises: Boot from the current boot image stored in the writable partition; A second boot prompt is displayed in response to a key press detected while the current boot image is being executed; Receive the switching command via the second startup prompt; Set the write-protected partition as the boot partition; and The starting device is reset.

11. The method of claim 9, wherein the signature is generated based on the contents of the updated boot image and the update version number.

12. The method of claim 9, wherein the method further comprises: Read the current version number associated with the current boot image; and Before replacing the current boot image, it is determined that the current version number is less than the update version number associated with the updated boot image.

13. The method of claim 9, wherein the method further comprises receiving an update command via the startup prompt, the update command including a filename associated with the update startup image.

14. The method of claim 13, wherein the filename includes one of a local filename and a remote address.

15. The method of claim 9, wherein the method further comprises: After replacing the current boot image, the writable partition is set as the boot partition; and The starting device is reset.

16. A non-transitory computer-readable storage medium for tangibly storing computer program instructions executable by a computer processor, the computer program instructions defining the following steps: Load the gold boot image from the write-protected partition of the memory array contained in the memory device; A startup prompt is displayed after the gold boot image is loaded; Receive an updated boot image, the updated boot image containing a signature; Read the public key from the write-protected partition; Verify the signature using the public key; and Replace the current boot image stored in the writable partition of the storage array with the updated boot image.

17. The non-transitory computer-readable storage medium of claim 16, wherein the step further comprises, prior to loading the gold boot image: Boot from the current boot image stored in the writable partition; A second boot prompt is displayed in response to a key press detected while the current boot image is being executed; Receive the switching command via the second startup prompt; Set the write-protected partition as the boot partition; and The starting device is reset.

18. The non-transitory computer-readable storage medium of claim 16, wherein the step further comprises: Read the current version number associated with the current boot image; and Before replacing the current boot image, it is determined that the current version number is less than the update version number associated with the updated boot image.

19. The non-transitory computer-readable storage medium of claim 16, wherein the step further comprises receiving an update command via the boot prompt, the update command comprising a filename associated with the update boot image.

20. The non-transitory computer-readable storage medium of claim 16, wherein the step further comprises: After replacing the current boot image, the writable partition is set as the boot partition; and The starting device is reset.

Images