Verifying software images

Abstract

This application relates to verifying software images. A software image can include different portions (e.g., different versions, different users) that can be verified using a hash associated with an underlying data structure of the portion of the software image. In some instances, a tree structure can be used to generate and store hashes (e.g., first hashes) associated with the software image, such that a previous hash can be used when calculating a hash associated with a new portion of the software image. To verify a portion of the software image, a command can be issued, and a second hash can be calculated using a current data structure of the software image. The second hash can be compared to the associated first hash, and the software image can be verified based on the hashes matching.

Description

[0001] Cross-reference

[0002] This patent application is the national phase application of International Patent Application No. PCT / US2021 / 037262, entitled “Authenticating Software Images,” filed June 14, 2021, by Duval et al., which claims the benefit of U.S. Patent Application No. 16 / 905,046, entitled “Authenticating Software Images,” filed June 18, 2020, each of which is assigned to the assignee and each of which is expressly incorporated herein by reference in its entirety. Technical Field

[0003] The technical field involves verifying software images. Background Technology

[0004] The following text generally refers to one or more memory systems, and more specifically, to verification software images.

[0005] Memory devices are widely used to store information in various electronic devices such as computers, wireless communication devices, cameras, digital displays, and the like. Information is stored by programming memory cells within the memory device into various states. For example, a binary memory cell can be programmed into one of two supported states, typically indicated by logic 1 or logic 0. In some instances, a single memory cell can support more than two states, any of which can be stored. To access the stored information, a component can read or sense at least one stored state in the memory device. To store information, a component can write to or program the states in the memory device.

[0006] Various types of memory devices and memory cells exist, including magnetic hard disks, random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase-change memory (PCM), self-selecting memory, chalcogenide memory technology, and others. Memory cells can be volatile or non-volatile. Even in the absence of an external power supply, non-volatile memory, such as FeRAM, can maintain its stored logic state for an extended period of time. Volatile memory devices, such as DRAM, may lose their stored state when disconnected from an external power supply. Summary of the Invention

[0007] A method is described. The method may include: receiving a first software image and a first command to store the first software image in a memory device; generating a first hash of the first software image based at least in part on first data associated with the first software image and the first command; storing the first hash in a non-volatile memory component of the memory device based at least in part on the generated first hash; receiving a second software image based at least in part on the first software image and a second command to store the second software image in the memory device; generating a second hash associated with the second software image based at least in part on the first hash of the first software image and the second command; storing the second hash and a first indication of the relationship between the second software image and the first software image in a non-volatile memory component of the memory device based at least in part on the generated second hash; and verifying the second software image by comparing the second hash with a calculated hash of the first hash and third data associated with the second software image through the memory device.

[0008] A system is described. The system may include: a memory array for storing data associated with one or more software images; a security component coupled to the memory array and configured to verify at least one of the one or more software images, the security component being configured to: receive a first software image and a first command to store the first software image in a memory device; generate a first hash of the first software image based at least in part on the first data associated with the first software image and the first command; store the first hash in the security component based at least in part on the generated first hash; receive a second software image based at least in part on the first software image and a second command to store the second software image in a memory device; generate a second hash associated with the second software image based at least in part on the first hash of the first software image and the second command; store the second hash and a first indication of the relationship between the second software image and the first software image in the security component based at least in part on the generated second hash; and verify the second software image by comparing the second hash with a calculated hash of the first hash and third data associated with the second software image.

[0009] A non-transitory computer-readable medium for storing computer-executable code is described. The non-transitory computer-readable medium may include computer-executable code executable by a processor to: generate a first hash of the first software image based at least in part on first data and a first command associated with the first software image; store the first hash in a non-volatile memory component based at least in part on the generation of the first hash; receive a second software image based at least in part on the first software image and a second command for storing the second software image; generate a second hash associated with the second software image based at least in part on the first hash of the first software image and the second command; store the second hash and a first indication of the relationship between the second software image and the first software image in the non-volatile memory component based at least in part on the generation of the second hash; and verify the second software image by comparing the second hash with a calculated hash of the first hash and third data associated with the second software image via a memory device. Attached Figure Description

[0010] Figure 1 Examples of systems supporting the verification of software images are shown, based on examples disclosed herein.

[0011] Figure 2 Examples of computational systems supporting verification software images are shown, based on examples disclosed herein.

[0012] Figure 3 An example of a process flowchart for supporting verification software images is shown, based on examples disclosed herein.

[0013] Figure 4 An example of a block diagram illustrating a supporting verification software image based on examples disclosed herein.

[0014] Figure 5 An example of a tree diagram showing a supporting verification software image based on examples disclosed herein.

[0015] Figure 6 An example of a process flowchart for supporting verification software images is shown, based on examples disclosed herein.

[0016] Figure 7 A block diagram of a memory device supporting verification software images, based on examples disclosed herein.

[0017] Figure 8 The flowchart illustrates one or more methods for verifying software images, based on examples disclosed herein. Detailed Implementation

[0018] Some computing systems may contain one or more virtual machines. A virtual machine can be an emulation of a computer system that provides the functionality of a physical computer. In some instances, a virtual machine may run on a host computing device. The virtual machine's source code may be stored in a software image. Similar to a physical computing device, a virtual machine can be accessed by visiting users (e.g., individuals using guest profiles) and can be periodically updated using software updates. In some cases, malicious actors (e.g., hackers) can modify the behavior of a virtual machine by altering one or more aspects of its code, including modifying code intended for software updates. Therefore, verifying the software image can be beneficial to prevent malicious actors from altering or gaining control of one or more aspects of the virtual machine.

[0019] This document describes techniques for verifying software images of virtual machines. Each virtual machine running on a host computing device can be accessed by different users, and its operating system and software programs can run on different versions. To verify software images of different virtual machines, indicators of data associated with different users and the version of the software image can be stored as nodes in a tree structure saved to a secure storage device. Additionally, a hash can be generated for each node, based on the relevant data indicators and the hashes of previous nodes in the tree (e.g., parent nodes). Using the hash of the parent node to generate the hash reduces the time required for hash generation and decreases the size of the software image data, thus reducing the space used to store the software image in the secure storage device.

[0020] In some cases, a software image can be verified during the boot sequence, which may refer to when the virtual machine is powered on or when the software program is powered off. During the boot sequence, the virtual machine can calculate a hash representing the current state of the software image being verified. The calculated hash can be compared with a related hash stored in a tree structure on a secure storage device. For example, if verifying a software program running on a second version (e.g., version 2.0), the calculated hash can be compared with a hash associated with the second version of the software image stored on the secure storage device.

[0021] If the compared hashes match, the software image can be verified (e.g., the software image may not have been altered). In these cases, the software image can proceed with the startup sequence (e.g., the software image can start). However, if the compared hashes do not match, the software image may have been altered. If the software image has been altered, the startup sequence may not complete, preventing user interaction with the virtual machine and thus preventing further harm from potential hacking attacks.

[0022] The features of this disclosure were initially described in, as seen in, [see also] Figure 1 and 2The features of this disclosure are described within the context of process flowcharts, block diagrams, and tree diagrams, as shown in [reference]. Figures 3 to 6 As described. These and other features of this disclosure are provided in reference to, for example, [see...]. Figure 7 and 8 The device diagram and flowchart of the verification software image described herein are further illustrated and described with reference to the diagrams.

[0023] Figure 1 An example of a system 100 supporting verification software images according to examples disclosed herein is shown. System 100 may include a terminal device 105 and a management server 185.

[0024] Terminal device 105 may include a super manager 117 and a storage device 112. The storage device may include a security component 110 configured to securely store at least software 130, a device-side key 135, software image data 140, and software hash data 125. In some cases, the security component 110 may store a management key 120. The device-side key 135 may be an instance of a server root key (SRK) or, for example, a set of two keys: a management public key and a device private key. The server root key or management public key may allow an entity possessing a copy of the SRK or management private key to manage the security component 110 by enabling the security features of the security component 10. The storage device 112 may include one or more components associated with the memory device operable to perform one or more authentication procedures as discussed herein. Terminal device 105 may be an instance of a vehicle's infotainment system, a personal computer, a portable electronic device, a server, or any other type of computing device.

[0025] Storage device 112 may be integrated into terminal device 105, which may include a super manager 117 that interacts with storage device 112. Super manager 117 may be implemented in hardware or software and is at least partially used to load software images from storage device 112 for running one or more virtual machines on terminal device 105. Before running virtual machines on terminal device 105, super manager may use storage device 112 to verify whether the software images of virtual machines have been tampered with and select not to run virtual machines whose code has been modified by malicious actors.

[0026] In some instances, storage device 112 may contain one or more software images. Before a software image is executable (e.g., before it is launched), the image can be verified to ensure that the underlying code has not been unintentionally altered. During the first part of image verification, management server 185 or any entity possessing host-side key 137 may issue a secure command to security component 110 to calculate and store hash 115 (e.g., a gold software hash) based on software image data 140 and device-side key 135. During subsequent parts of image verification, storage device 112 may calculate a hash based on the software image data 140 of the image being verified (e.g., current data). Storage device 112 may compare the hash with hash 115 to verify the software image.

[0027] System 100 may include a management server 150 that communicates with terminal device 105. Management server 150 may include at least a first software image 155, a second software image 160, and a host-side key 137. Host-side key 137 may be an SRK or, for example, an instance of a set of two keys managing a private key and a device public key. When management server 185 downloads software image data to storage device 112, it may also issue a security command to security component 110 to generate hash 115.

[0028] In some instances, management server 185 may optionally generate a patch file representing the differences between the first software image 155 and the second software image 160. Management server 185 may then optionally download the patch file to the software image data 140 component of storage device 112.

[0029] This document describes techniques for verifying software images on storage device 112. In some instances, a hash 115 associated with the software image (e.g., a gold software hash 115) may be generated and stored in a tree structure. Different versions of the hash of the software image may be stored as nodes in the tree structure, and a corresponding hash may be generated using the hash of the parent node. The hash 115 stored in the tree structure may then be compared with the corresponding hash generated by storage device 112 to verify the software image. Using a tree structure to verify software images can mitigate malicious attempts to modify the underlying code of the software image on storage device 112. Furthermore, the tree structure can reduce the amount of storage required to verify the corresponding software image, while improving the startup time of terminal device 105.

[0030] Figure 2An example of a computing system 200 supporting the verification of software images, as disclosed herein, is shown. The computing system 200 may include one or more host computing devices 215 capable of running one or more software images 205. The host computing devices 215 may be configured to communicate with a secure storage device 225. At least a portion of the secure storage device 225 may be accessible to one or more host computing devices 215, and another portion of the secure storage device 225 may be inaccessible to one or more host computing devices 215. In some instances, the methods described herein can be used to verify the software image 205, which can reduce the time and storage space required to verify the corresponding software image 205.

[0031] The computing system 200 may include multiple software images 205, which may be instances of software images 205. One or more virtual machines may run through a single host computing device 215. For example, host computing device 215-a may run virtual machines associated with software images 205-a, 205-b, and 205-n. Alternatively or additionally, host computing device 215-b may run virtual machines associated with software images 205-c, 205-d, and 205-z. In some instances, n and z may be positive integers, such that host computing devices 215-a and 215-b can run any number of virtual machines. Host computing device 215 may be a server or may contain servers.

[0032] Each host computing device 215 may include one or more super managers 210. Corresponding virtual machines may run on super managers 210-a or 210-b associated with host computing devices 215-a and 215-b, respectively. Each super manager 210 may be or may contain computer software, firmware, or hardware configured to run the operating system of each virtual machine. The super manager 210 may present a virtual operating platform to the virtual machines and manage the execution of the operating system run by each virtual machine. Each virtual machine running on a single super manager 210 may contain a software image that is verified before running. In some instances, different virtual machines may run different versions of the software image and / or may contain guest profiles that can be verified before running.

[0033] Each host computing device 215 may include local random access memory to perform the functions described herein. One or more host computing devices 215 may store information about secure storage device 225. At least a portion of secure storage device 225 may be accessible through a corresponding super manager 210 (e.g., independent of super manager 210), or may be a hardware component of the corresponding super manager 210. Secure storage device 225 may be configured to store operating systems or software running by individual virtual machines. In some instances, secure storage device 225 may store software updates to be provided to one or more virtual machines. Secure storage device 225 may be configured to verify the software image 205 upon initialization or startup to verify its security. A failure of the verification process may indicate that the code associated with software image 205 has been tampered with or altered in some way. For example, secure storage device 225 may verify the code of a virtual machine before the virtual machine is bootable.

[0034] Host computing device 215 and / or virtual machine may communicate with secure storage device 225. For example, host computing device 215-a and host computing device 215-b may each communicate with secure storage device 225. Host computing device 215 may be configured to provide data to secure storage device 225, and secure storage device 225 may store data in an internal tree structure inaccessible to host computing device 215. Secure storage device 225 may be configured to perform one or more security operations and / or one or more authentication operations against any software image 205 or virtual machine associated with host computing device 215 or a program running through software image 205 or virtual machine. Secure storage device 225 may include a portion of memory inaccessible to host computing device 215, super manager 210, one or more software images 205 or a combination thereof. The tree may include an initial software image (or an index to the location where the initial software image is stored) and one or more branches with corresponding nodes. Each node in the tree structure can represent data associated with the base image (e.g., the address or index of the data) and a corresponding hash used for verification. Individual hashes can be generated based on previous hashes in different versions of the tree or base image (e.g., due to software updates, based on the hash of the parent node).

[0035] In some cases, virtual machines can be sensitive to hacking. For example, a malicious actor could attempt to gain access to the virtual machine via the host computing device by modifying one or more aspects of its code. As described herein, secure storage device 225 can be configured to verify software image 205 before the code used to ensure that software image 205 has not been tampered with. Secure storage device 225 can use a tree structure to verify the software image, mitigating the consequences of such a hack by verifying the virtual machine via nodes in the tree structure before the corresponding virtual machine starts. Furthermore, the tree structure reduces the amount of storage used to verify the corresponding software image, while improving virtual machine startup time.

[0036] Figure 3 A flowchart 300 illustrating an example process for supporting verification software images, as disclosed herein, is provided. The flowchart 300 can be used to illustrate, as referenced... Figure 2 The operation of one or more components of the described computing system 200. For example, process flowchart 300 can illustrate the verification as referenced. Figure 2 The software image 205 is described. The process flowchart 300 illustrates the operation of the host computing device 305 and the secure storage device 310. In some instances, the host computing device 305 may implement aspects of a virtual machine.

[0037] In some instances, the image (e.g., software image) of the virtual machine can be verified (e.g., during the boot sequence). The software image can be an instance of an operating system, software program, virtual machine, or the like. Because virtual machines can be sensitive to hacking attacks where one or more aspects of the software image's code can be modified, it can be beneficial to verify the software image before the virtual machine boots. If the code has been modified, and the virtual machine boots are prevented when the code has been modified, malicious actions can be detected or fixed before a user has access to the virtual machine. In some instances, to verify the virtual machine, hashes of different versions and / or different user profiles associated with the software image can be stored in secure storage device 310. In some instances, the hash can store an indicator (e.g., a key) of the associated data.

[0038] At 315, host computing device 305 can recognize a software image (e.g., a base image) associated with a virtual machine. Host computing device 305 can store software image 320 on secure storage device 310. Host computing device 305 can generate a save command 325 associated with software image 320 and send the save command to secure storage device 310. Software image 320 can be an instance of a virtual machine, operating system, software program, a set of user settings for an operating system or program, or the like. Host computing device 305 can transfer software image 320 and save command 325 to secure storage device 310.

[0039] Secure storage device 310 may receive command 325 and software image 320 from host computing device 305. Command 325 (e.g., a save command) may be used to save data associated with the software image, allowing secure storage device 310 to verify the software image 320 later during initialization or startup. In some instances, command 325 may be used with the base version of the virtual machine. In some instances, command 325 may be used with an updated version of the virtual machine. In some instances, command 325 may be used to save data associated with a specific user (e.g., a guest user) of the virtual machine for verification. Alternatively, command 325 may indicate the memory address (or address range) of the software image 320 to be saved to secure storage device 310. Thus, an initial save command 325 may be received when the operating system or software program is first installed or during the initial startup sequence or setup for a specific user. In other instances, host computing device 305 may periodically save snapshots of the software image associated with the virtual machine to secure storage device 310. Command 325 may be sent to secure storage device 310 based on the snapshot being saved.

[0040] At 330, the secure storage device 310 may generate a hash (e.g., a cryptographic hash, a first hash) of the software image 320 based on the received save command 325. For example, the software image 320 may be a base image as described herein, and the hash may be generated based on data or code associated with the base image. A secure hash algorithm (SHA) may be used, for example, to generate the hash.

[0041] The secure storage device 310 may also generate an identifier associated with the software image 320 and / or a hash of the software image 320. The secure storage device 310 may identify data associated with the software image 320 and generate an indication of the amount of information stored in the tree structure. In some instances, the secure storage device 310 may identify the address (e.g., address range) of the underlying data and use said address as part of the indication. The identifier may be saved to the secure storage device 310 and may be used to verify the software image of a virtual machine. In some instances, some or all of the indication or key may be generated by the host computing device 305 and sent to the secure storage device 310. The identifier may be associated with a first version (e.g., version 1.0) of an operating system or a particular software program, or may be associated with an initial data structure for a particular user. This identifier may be referred to as the “base image” and may be the initial node in the tree structure stored in the secure storage device 310. Any additional nodes stored in the tree structure may depend on the base image.

[0042] At 335, the hash and identifier may be stored in a portion of a secure storage device 310 inaccessible to the host computing device 305. The hash generated by the secure storage device 310 may be an instance of a hash used to verify other hashes during the initialization process of the software image. Therefore, the hash, which is part of the hash generated for the save command 325, is stored for future verification procedures and is inaccessible from the host computing device. The inaccessibility of the hash prevents hackers from altering the stored hash, thus making the verification process more reliable. The indication may include a pointer to a memory storing the relevant software image. The indication may include information about how the relevant software image relates to other software images of the same program or virtual machine. For example, an identifier may indicate that the software image is an updated version of another base version. Reference Figure 4 and 5 Additional details are described regarding the relationship between software versions. The portion of secure storage 310 storing the identifier and hash may include non-volatile memory and may be inaccessible to host computing device 305. Because the identifier and hash are inaccessible to host computing device 305, the data may be invisible to malicious actors, while still being accessible to secure storage 310 during the verification process.

[0043] At 340, the host computing device 305 may optionally receive one or more software updates. For example, the host computing device 305 may receive software updates for the operating system or software programs associated with the virtual machine. When the host computing device 305 receives a software update, it may install the update.

[0044] At 345, a software update may be performed on the virtual machine as needed. In some instances, during a software update, the virtual machine may receive (e.g., download) the entire file containing the updated version of the software image. In other instances, the host computing device 305 may receive a file containing only the differences between the base image and the updated version (e.g., a patch file). In either case, a software update may be performed on the virtual machine.

[0045] In some instances (not shown in the figures), software updates may be provided to host computing device 305 via an external server. As discussed herein, a malicious actor could attempt to gain access to the virtual machine via host computing device 305. Secure storage device 310 may generate an initial hash of the software image associated with the software update and use the hash during initialization to verify the contents of the software update (e.g., verify files).

[0046] The host computing device 305 can transfer the software image 350 associated with the software update and the save command 355 to the secure storage device 310. The software image 350 may be associated with the software image 320 and may contain patches applicable to the software image 320 to complete the software update.

[0047] At 360, the secure storage device 310 may generate a hash (e.g., a password hash, a first hash) of the software image 350 based on receiving a save command 355. The secure storage device 310 may also generate an identifier associated with the software image 350 and / or a hash of the software image 350. When generating a hash of the software image 350 is based on an updated version of the base image (e.g., software image 320), the secure storage device 310 may generate a new hash using the first hash and at least a portion of the software image 350, instead of using the software image 320 and the software image 350.

[0048] Secure storage device 310 can identify data associated with software image 350 and generate an indication of reducing the amount of information stored in the tree structure. In some instances, secure storage device 310 can identify the address (e.g., address range) of the underlying data and use said address as part of the indication. The identifier can be saved to secure storage device 310 and can be used to verify the software image of the virtual machine. In some instances, some or all of the identifiers can be generated by host computing device 305 and sent to secure storage device 310. Because this is a software update, the identifier can be associated with a second or subsequent version (e.g., version 2.0) of the operating system or a particular software program. This identifier can be a secondary node in the tree structure stored in secure storage device 310. (See reference...) Figure 5 As described, the indication of a secondary node may contain information that connects the secondary node to other nodes in the tree structure.

[0049] At 365, the hash and identifier can be stored in a portion of a secure storage device 310 inaccessible to the host computing device 305. The hash generated by the secure storage device 310 can be an instance of a hash used to verify other hashes during the initialization process of the software image. Therefore, the hash, which is part of the hash generated for the save command 355, is stored for future verification procedures and is inaccessible from the host computing device. The inaccessibility of the hash prevents hackers from altering the stored hash, thus making the verification process more reliable. The indication may include a pointer to a memory storing the relevant software image. The indication may include information about how the relevant software image relates to other software images of the same program or virtual machine. For example, an identifier may indicate that the software image is an updated version of another base version. Reference Figure 4 and 5Additional details are described regarding the relationship between software versions. The portion of secure storage 310 storing the identifier and hash may include non-volatile memory and may be inaccessible to host computing device 305. Because the identifier and hash are inaccessible to host computing device 305, the data may be invisible to malicious actors, while still being accessible to secure storage 310 during the verification process.

[0050] In some instances, command 355 can be used to save data associated with an identified guest user of the virtual machine. In some instances, a guest profile can be created on the virtual machine, and the save command can be used to associate a software image with the guest. In some instances, secure storage device 310 can update one or more stored identifiers and / or hashes. For example, a software image may experience data changes not associated with a software update. In these cases, data changes can be communicated to secure storage device 310, and secure storage device 310 can update any stored identifiers associated with the software image. In other instances, secure storage device 310 can compute (e.g., recompute) one or more hashes associated with the updated data.

[0051] although Figure 3 The diagram illustrates a tree structure for storing items from a single virtual machine to secure storage 310, but items from multiple virtual machines can be stored to secure storage 310 as parts of the same or different tree structures. For example, some or all virtual machines associated with a software image and running on host computing device 305 can store items (e.g., nodes) in a tree structure. See below for reference. Figure 4 and 5 Description items and instances of tree structures.

[0052] Figure 4 An example of a block diagram 400 supporting verification software image is shown, based on examples disclosed herein. Block diagram 400 may illustrate the generation of storage to a secure storage device (e.g., as referenced). Figure 3 The described secure storage device 310) contains one or more hashes. For example, block diagram 400 may illustrate applying a hash algorithm to different strings 405, and applying it to the resulting hash 410 based on the applied hash algorithm. In some instances, it may respond to, as referenced... Figure 3 The hash algorithm is applied to the described command (e.g., the save command).

[0053] Some updates to the virtual machine's code can be relatively small compared to the size of the base image. If the hash of the base image is calculated every time the virtual machine version is verified, then it consumes significant computational resources. To reduce the response time to save commands (as referenced...) Figure 3 (as described) or measurement commands (as referenced) Figure 6The amount of computational resources used to generate a hash (as described) can be reduced by using an earlier version of the hash to generate a subsequent version. This can reduce the amount of computational resources used for hashing because it reduces the amount of information being hashed.

[0054] In a first instance, a hash algorithm (e.g., SHA) may be applied to a base image 415. The base image may refer to a first version of a software image (e.g., version 1.0), or may be associated with an initial data structure of a particular user, operating system, or software program. When the hash algorithm is applied to the base image 415, the resulting hash may be a base image hash 420 (e.g., Hash_b1). In some instances, the base image hash 420 may be stored in a secure storage device as described herein.

[0055] In a second instance, a hash algorithm (e.g., SHA) may be applied to string 405, which includes a base image hash 420 and a second version 425 of the software image, a data structure specific to a user, operating system, or software program. The second version 425 may represent a modified version of the base image 415. Therefore, in the tree structure described herein, the second version 425 may depend on the base image. To generate the second image hash 430 (e.g., Hash_b1v2), the hash of the base image (e.g., base image hash 420) and the code for the second version 425 may be used. In some instances, the second image hash 430 may be stored in a secure storage device as described herein.

[0056] In another instance, a hash algorithm (e.g., SHA) may be applied to string 405, which includes a base image hash 420 and a data structure associated with visitor image 435. Visitor image 435 may represent a modified version of base image 415. Therefore, in the tree structure described herein, visitor image 435 may depend on the base image. To generate visitor hash 440 (e.g., Hash_b1g1), a hash of the base image (e.g., base image hash 420) and the code of visitor image 435 may be used. In some instances, visitor hash 440 may be stored in a secure storage device as described herein.

[0057] A hash algorithm (e.g., SHA) can be applied to string 405, which contains visitor hash 440 and second-version hash 430, and a data structure associated with visitor image 435. Visitor image 435 may represent a modified version of the underlying second-version 425. Therefore, in the tree structure described herein, visitor image 435 may depend on second-version 425. To generate second-version visitor hash 445 (e.g., Hash_b1v2g1), a hash of second-version 425 (e.g., second-version hash 430) and the code of visitor image 435 can be used. In some instances, visitor version visitor hash 445 may be stored in a secure storage device as described herein.

[0058] Alternatively, a hash algorithm (e.g., SHA) can be applied to the string, which contains visitor hash 440 and second version 425. Second version 425 may represent a modified version of the base image 415. Therefore, in the tree structure described herein, the second version may depend on the base image 415. To generate visitor second version hash 450 (e.g., Hash_b1g1v2), visitor hash 440 of visitor 435 (e.g., visitor hash 440) and the code of second version 425 can be used. In some instances, visitor second version hash 450 may be stored in a secure storage device as described herein.

[0059] Figure 5 An example of a tree diagram 500 supporting verification software images is shown, based on examples disclosed herein. Tree diagram 500 may illustrate one or more hashes (e.g., as referenced). Figure 4 The resulting hash (410) described above and stored in a secure storage device (e.g., as referenced) Figure 3 The relevant identifier of the described secure storage device 310. In some instances, it may be in response to, as referenced... Figure 3 The virtual machine described receives one or more commands (e.g., save command) and stores hashes and identifiers.

[0060] The tree structure can store the identifier 505 and hash 510 associated with the base image. As discussed herein, the base image may refer to a first version of a software image (e.g., version 1.0), or may be associated with an initial data structure of a specific user, operating system, or software program. When a hash algorithm is applied to the base image (e.g., to identifier 505), the resulting hash may be hash 510, which may be as described in the reference... Figure 4 An instance of the described underlying image hash 420 (e.g., Hash_b1). Identifier 505 and hash 510 can be stored as initial nodes in a tree structure.

[0061] In some instances, the data structure of the base image can be updated to a second version (e.g., version 2.0). Therefore, the tree structure can store the identifier 515 and hash 520 associated with the updated image. As discussed herein, hash 520 can be generated by applying a hashing algorithm to the base image hash (e.g., hash 510) and the code associated with the second version. The resulting hash can be hash 520, which can be as described in the reference. Figure 4 The second image hash 430 described is an instance of (e.g., Hash_b1v2). Because the second version can be a modified version of the base image, the identifier 515 can indicate that the node is a related node from the base node associated with the base image.

[0062] Alternatively, the data structure of the base image can be updated to a third version (e.g., version 3.0). Thus, the tree structure can store the identifier 525 and hash 530 associated with the updated image. As discussed herein, hash 520 can be generated by applying a hashing algorithm to the base image hash (e.g., hash 510) and the code associated with the third version. The resulting hash can be hash 530, which can be an instance of the third image hash 530 (e.g., Hash_b1v3). Because the third version can be a modified version of the base image, identifier 525 can indicate that the node is a related node from the base node associated with the base image.

[0063] The base image data structure can be updated to include visitor profiles. Therefore, a tree structure can store identifiers 535 and hashes 540 associated with the updated image. Hash 540 can be generated by applying a hash algorithm to the base image hash (e.g., hash 510) and the code associated with the visitor profile. Therefore, a hash algorithm can be applied to hash 510 and identifiers 535. The resulting hash can be hash 540, which can be as shown in the reference. Figure 4 An instance of the described visitor hash 440 (e.g., Hash_b1g1). Because the visitor profile may be a modified version of the base image, identifier 535 may indicate that the node is a related node from the base node associated with the base image.

[0064] The data structure of the third version of the base image can be updated to include visitor profiles. Therefore, a tree structure can store the identifier 545 and hash 550 associated with the updated image. Hash 550 can be generated by applying a hash algorithm to the third version hash (e.g., hash 530) and the code associated with the visitor profile. Therefore, a hash algorithm can be applied to hash 530 and identifier 545. The resulting hash can be hash 550, which can be an instance of the third version visitor hash (e.g., Hash_v3g1). Because the third version visitor profile can be a modified version of the third version and the base image, the key can indicate a related node from the node associated with the third version, which is a related node from the base node associated with the base image.

[0065] The data structure of the visitor profile for the base image can be updated to a second version. Therefore, a tree structure can store the identifier 555 and hash 560 associated with the updated image. Hash 560 can be generated by applying a hash algorithm to the visitor hash (e.g., hash 540) and the code associated with the second version. Therefore, a hash algorithm can be applied to hash 540 and identifier 555. The resulting hash can be hash 560, which can be as shown in the reference. Figure 4 The described instance of visitor second version hash 450 (e.g., Hash_g1v2). Because the second version can be a modified version of the visitor profile, the key can indicate a related node from the node associated with the visitor profile, which is a related node from the base node associated with the base image.

[0066] See also Figure 5 Each of the described identifiers and hashes is stored in a secure storage device, such as referenced in [reference]. Figure 3 The described secure storage device 310. In some instances, due to space limitations or due to outdated versions or user profiles, it may be necessary to delete one or more identifiers from the tree diagram. In some instances, an erase command can be issued to delete one or more nodes from the tree diagram.

[0067] In a first instance, an erase command can be issued to erase the node associated with identifier 515 and hash 520. Because the node does not contain any additional related nodes (e.g., the node depends only on the base image node), the erase command removes the key and hash 520 from the tree structure. In an additional instance, an erase command can be issued to erase the node associated with identifier 525 and hash 530. Because the node can be an intermediate node (e.g., the node associated with identifier 545 and hash 550 depends on the node associated with the erase command), the erase command can be ignored. The erase command can be ignored, for example, until the node associated with identifier 545 and hash 550 is removed from the tree structure.

[0068] In another instance, an erase command can be issued to erase the node associated with identifier 535 and hash 540. Because nodes can be intermediate nodes (e.g., the node associated with identifier 555 and hash 560 depends on the node associated with the erase command), the erase command can be configured to initiate a reconstruction of nodes in the tree structure. For example, hash 510 can be used to regenerate (e.g., recalculate) hash 560, so that the node associated with identifier 555 and hash 560 depends on the base image. Once hash 560 is regenerated, the associated node can depend on the base image, and intermediate nodes (e.g., the node associated with identifier 535 and hash 540) can be deleted.

[0069] Figure 6 An example of a process flowchart 600 supporting verification software images is shown, based on examples disclosed herein. Process flowchart 600 can illustrate, as referenced... Figure 2 The operation of one or more components of the described computing system 200. For example, process flowchart 600 can illustrate the verification as referenced. Figure 2 The software diagram 205 is described. The process flowchart 600 illustrates the operation of the host computing device 605 and the secure storage device 610.

[0070] The secure storage device can be configured to verify the software image of a host computing device. To verify the software image, the secure storage device may be able to execute save commands, erase commands, measure commands, other commands, or combinations thereof. (See reference...) Figure 3 As described, hashes can be generated and securely stored using a save command for later comparison during the startup sequence. (See reference...) Figure 5 As described, a stored hash can be deleted using an erase command for use in a verification procedure. As described herein, a software image can be verified during an initialization procedure (e.g., a startup sequence) using a measurement command by generating a hash of the software image and comparing that hash with a stored hash (e.g., stored using a save command).

[0071] In some instances, the host computing device 605 may contain a software image to be verified (e.g., during the boot sequence). The software image may be or may contain an operating system, software programs, or the like. Because virtual machines can be sensitive to hacking attacks where one or more aspects of the software image's code can be modified, it can be beneficial to verify the software image before the virtual machine starts. If the code has been modified, and the virtual machine is prevented from starting when the code has been modified, malicious actions can be detected or fixed before a user has access to the virtual machine. In some instances, programs associated with the software image can be prevented from running, thus preventing additional damage from hacking attacks. In some instances, software generated and stored to, as shown in [reference], can be used. Figures 3 to 5The described tree structure is used to verify the software image. In some cases, the startup sequence may or may not be started based on the verification procedure.

[0072] At 615, a startup sequence may optionally be initiated at host computing device 605. This startup sequence may be initiated when host computing device 605 is powered on, or when a virtual machine associated with host computing device 605 starts, for example, when a user (or guest) attempts to access the virtual machine, or when a software program starts (e.g., boots up). In some instances, an instruction may be transmitted to secure storage device 610 when the startup sequence is initiated. This instruction may initiate a verification process for the software image (e.g., a virtual machine) being started.

[0073] The host computing device 605 may transmit a measurement command 620 based on a startup sequence. The command 620 (e.g., a measurement command) may be used to initiate a verification process for a software image of a virtual machine. For example, the command 620 may be used to verify the operating system associated with the virtual machine. In other instances, the measurement command 620 may be used to verify a user profile of the virtual machine (e.g., a guest profile) or to verify a specific software program installed on the host computing device 605. The command 620 may contain an indication that a software image is being verified (e.g., a version of a software hash is being verified). The host computing device 605 may also transmit a software image 625 (or an indication of where the software image 625 is stored) to a secure storage device 610 as part of sending the measurement command 620. The features described with reference to 630, 635, and 640 may be examples of a verification process executed by the secure storage device 610.

[0074] At 630, based on received command 620, secure storage device 610 can identify the software image 625 associated with command 620. For example, secure storage device 610 can determine which node or storage hash in the stored tree structure is associated with the measurement command. Secure storage device 610 can make this determination based on information contained in measurement command 620, the software image 625 itself, or a combination thereof. Command 620 can identify a specific operating system, a specific software program, a specific user, or the like. In some instances, host computing device 605 can identify the location (e.g., address range) of the underlying software image for verification.

[0075] At 635, the host computing device 605 may generate a hash (e.g., a password hash, a second hash) of the software image 625. The hash generated in response to the measurement command 620 may be a hash of the code associated with the software image 625 that was attempted to be started. Therefore, if the code associated with the software image 625 has been changed from its expected state (e.g., from its correct state due to malicious action), then the verification procedure may fail. This can be used in response to, as referenced... Figure 3The same algorithm used to generate the hash stored in secure storage device 310 by the described save command generates the hash at 635. For example, the hash can be generated using SHA. In some instances, the hash can be generated by host computing device 605 and transmitted to secure storage device 610 using measurement command 620.

[0076] At 640, the secure storage device 610 can compare the calculated hash with the stored hash (e.g., a gold hash). In response to a save command (as referenced...) Figure 3 As described, the secure storage device can store the hash in a portion of the memory that is inaccessible to the host computing device. By causing the secure storage device to store the first hash in inaccessible memory, and by causing the secure storage device to subsequently perform a verification procedure (e.g., comparing the calculated hash with the expected hash), the verification is unlikely to be maliciously attacked by a hacker. The secure storage device 610 can compare the hash generated at 635 (e.g., the second hash) with the corresponding hash (e.g., the gold hash) stored in the secure storage device 610.

[0077] Secure storage device 610 may transmit an indication 645 of the result of a hash comparison to the host computing device. This indication may include whether a first hash matches a second hash. For example, if the hashes match, secure storage device 610 may transmit a command to host computing device 605 to continue (e.g., execute or complete) the boot sequence. In other instances, if the hashes do not match, secure storage device 610 may transmit a command to host computing device 605 to terminate the boot sequence (e.g., not launch the software image). In some instances, if the hashes do not match, secure storage device 610 may avoid transmitting any additional information to host computing device 605 as part of the boot sequence. In these instances, avoiding transmitting information in response to other commands in the boot sequence may cause the boot sequence to fail, and the virtual machine or program may not launch. In some instances, if secure storage device 610 does not transmit a boot command to host computing device 605, the software image may not be verified (e.g., the boot sequence may not complete).

[0078] At 650, the host computing device 605 may attempt to continue the startup sequence of the software image. In some instances, the host computing device 605 may start the software image based on a match between the first and second hashes. Alternatively, when the hashes match, the host computing device 605 may receive an instruction from the secure storage device 610 to continue the startup sequence. In other instances, at 655, the host computing device 605 may avoid starting the software image based on a mismatch between the first and second hashes. In some instances, the host computing device 605 may attempt to continue the startup sequence and may continue to issue startup commands and requests for data to the secure storage device 610. In these cases, if the verification fails, the secure storage device 610 may avoid fulfilling the request for data, thereby invalidating the startup sequence. The host computing device 605 may avoid starting the software image based on receiving commands from the secure storage device 610 or based on not receiving any commands from the secure storage device 610.

[0079] Figure 7 A block diagram 700 illustrates a memory device 705 supporting a verification software image according to an example disclosed herein. The memory device 705 may be as described in the references... Figures 1 to 6 Examples of aspects of the described memory device. Memory device 705 may include a receiving component 710, a generating component 715, a storing component 720, a verifying component 725, a selecting component 730, an identifying component 735, an erasing component 740, an updating component 745, a comparing component 750, and a transmitting component 755. Each of these components may communicate with each other directly or indirectly (e.g., via one or more buses).

[0080] The receiving component 710 can receive a first software image and a first command to store the first software image in a memory device. In some instances, the receiving component 710 can receive a second software image based on the first software image and a second command to store the second software image in a memory device. In some instances, the receiving component 710 can receive a first command for storing a first hash, storing a second hash, or both, based on generating a second hash. In some instances, the receiving component 710 can receive an erase command to erase the stored second hash.

[0081] The generation component 715 may generate a first hash of the first software image based on first data and a first command associated with the first software image. In some instances, the generation component 715 may generate a second hash associated with a second software image based on the first hash of the first software image and a second command. In some instances, the generation component 715 may generate a first indication of the first software image based on receiving the first software image, wherein storing the first hash and the first indication is based on generating the first indication.

[0082] In some instances, the generating component 715 may generate a first indication of the relationship between the second software image and the first software image based on receiving the second software image, wherein storing the second hash and the first indication is based on generating the first indication. In some instances, the generating component 715 may generate a third hash of third data based on receiving a third command.

[0083] Storage component 720 may store a first hash in a non-volatile memory component of the memory device based on the generation of a first hash. In some instances, storage component 720 may store a second hash and a first indication of the relationship between a second software image and a first software image in a non-volatile memory component of the memory device based on the generation of a second hash. In some instances, storage component 720 may store a third hash of third data in a volatile memory component of the memory device based on the generation of a third hash.

[0084] Verification component 725 can verify the second software image via a memory device by comparing a second hash with a first hash and a calculated hash of third data associated with the second software image. In some instances, verifying the second software image includes determining whether the third hash of the third data is the same as the second hash associated with the second software image by comparing the third hash of the third data with the second hash associated with the second software image.

[0085] In some instances, verification component 725 may avoid verifying a second software image by generating a notification based on determining that a third hash of the third data differs from a second hash, wherein the notification contains an indication that the third data differs from the second hash. In some instances, verification component 725 may avoid verifying a second software image by issuing a fourth command based on determining that a third hash of the third data differs from a second hash associated with the second software image, wherein the fourth command contains an instruction to avoid initiating a startup sequence.

[0086] The selection component 730 can select a first hash to be used to generate the second hash based on the relationship between the second software image and the first software image, wherein generating the second hash is based on selecting the first hash.

[0087] The recognition component 735 can recognize third data based on receiving a first command, wherein the third data includes data contained in the second data associated with the second software image but not included in the first data. In some instances, the recognition component 735 can recognize changes in the second data associated with the second software image relative to the first data.

[0088] Erasing component 740 can erase a second hash and a first indication of the relationship between the second software image and the first software image stored in a non-volatile memory component based on receiving an erase command. In some instances, erasing component 740 can erase one or more additional hashes and indications of the correspondence between the additional hashes and the second software image before erasing the second hash and the first indication of the relationship between the second software image and the first software image.

[0089] The update component 745 can update the first indication of the relationship between the second software image and the first software image based on the identification of changes in the second data.

[0090] The comparison component 750 can compare the third hash of the third data with the second hash associated with the second software image based on storing the third hash of the third data to a volatile memory component.

[0091] The transmission component 755 can transmit a notification to the host system. In some instances, the transmission component 755 can issue a fourth command based on determining that a third hash of the third data matches a second hash associated with the second software image, wherein the fourth command contains instructions to initiate a startup sequence.

[0092] Figure 8 A flowchart illustrating one or more methods 800 supporting the verification of software images, based on examples disclosed herein. Operation of method 800 may be implemented via a memory device or a component thereof, as described herein. For example, operation of method 800 may be implemented via, as shown in [reference] Figure 7 The described memory device is used for execution. In some instances, the memory device may execute an instruction set to control the functional elements of the memory device to perform the described functions. Alternatively, the memory device may use dedicated hardware to perform aspects of the described functions.

[0093] At 805, the memory device can receive a first software image and a first command to store the first software image in the memory device. The operation of 805 can be performed according to the methods described herein. In some instances, aspects of the operation of 805 can be described as follows: Figure 7 The described receiving component is used for execution.

[0094] In 810, the memory device can generate a first hash of the first software image based on first data and a first command associated with the first software image. The operation of 810 can be performed according to the methods described herein. In some instances, aspects of the operation of 810 can be described as follows: Figure 7 The described generation components are used for execution.

[0095] At 815, the memory device may store the first hash in a non-volatile memory component of the memory device based on the generation of the first hash. The operation of 815 may be performed according to the method described herein. In some instances, aspects of the operation of 815 may be described as follows: Figure 7 The described storage component is used to execute this.

[0096] At 820, the memory device may receive a second software image based on the first software image and a second command to store the second software image in the memory device. The operation of 820 may be performed according to the method described herein. In some instances, aspects of the operation of 820 may be described as follows: Figure 7 The described receiving component is used for execution.

[0097] In 825, the memory device can generate a second hash associated with the second software image based on a first hash of the first software image and a second command. The operation of 825 can be performed according to the method described herein. In some instances, aspects of the operation of 825 can be described as follows: Figure 7 The described generation components are used for execution.

[0098] At 830, the memory device may store, based on the generation of a second hash, a first indication of the relationship between the second software image and the first software image in a non-volatile memory component of the memory device. Operation of 830 may be performed according to the method described herein. In some instances, aspects of the operation of 830 may be described as follows: Figure 7 The described storage component is used for execution.

[0099] In 835, the memory device can verify the second software image by comparing a second hash with a calculated hash of a first hash and third data associated with the second software image. The operation of 835 can be performed according to the method described herein. In some instances, aspects of the operation of 835 can be described as follows: Figure 7 The described verification component is used to perform this.

[0100] In some instances, the device described herein may perform one or more methods, such as method 800. The device may include features, components, or instructions (e.g., a non-transitory computer-readable medium storing instructions executable by a processor) for performing the following operations: receiving a first software image and a first command to store the first software image in a memory device; generating a first hash of the first software image based on first data associated with the first software image and the first command; storing the first hash in a non-volatile memory component of the memory device based on the generated first hash; receiving a second software image based on the first software image and a second command to store the second software image in the memory device; generating a second hash associated with the second software image based on the first hash of the first software image and the second command; storing the second hash and a first indication of the relationship between the second software image and the first software image in the non-volatile memory component of the memory device based on the generated second hash; and verifying the second software image by comparing the second hash with a calculated hash of the first hash and third data associated with the second software image via the memory device.

[0101] Method 800 and some examples of the devices described herein may further include operations, features, components, or instructions for generating a first indication of a first software image based on receiving a first software image, wherein storing the first hash and the first indication may be based on generating the first indication.

[0102] Method 800 and some examples of the devices described herein may further include operations, features, components, or instructions for generating a first indication of the relationship between the second software image and the first software image based on receiving the second software image, wherein storing the second hash and the first indication may be based on generating the first indication.

[0103] Method 800 and some examples of the devices described herein may further include operations, features, components, or instructions for selecting a first hash to generate a second hash based on a relationship between a second software image and a first software image, wherein generating the second hash may be based on selecting the first hash.

[0104] Method 800 and some instances of the apparatus described herein may further include operations, features, components, or instructions for receiving a first command for storing a first hash, storing a second hash, or both, based on generating a second hash, and for identifying third data based on receiving the first command, wherein the third data includes data that may be included in the second data associated with the second software image but may not be included in the first data.

[0105] Method 800 and some examples of the apparatus described herein may further include operations, features, components, or instructions for receiving an erase command to erase the stored second hash, and for erasing, based on receiving the erase command, the second hash stored in the non-volatile memory component and a first indication of the relationship between the second software image and the first software image.

[0106] Method 800 and some examples of the apparatus described herein may further include operations, features, components, or instructions for erasing one or more additional hashes and indications of the correspondence between the additional hashes and the second software image prior to erasing the second hash and the first indication of the relationship between the second software image and the first software image.

[0107] Method 800 and some examples of the devices described herein may further include operations, features, components, or instructions for identifying changes in second data associated with a second software image relative to first data, and updating the relationship between the second software image and the first software image based on the identified changes in the second data.

[0108] In some instances of method 800 and the devices described herein, a set of hashes of a set of software images stored in a non-volatile memory component may be inaccessible to the host system.

[0109] Method 800 and some examples of the devices described herein may further include operations, features, components, or instructions for receiving a third command in the memory device for determining whether second data associated with the second software image can be modified, wherein the third command includes a first indication of the relationship between the second software image and the first software image.

[0110] Method 800 and some examples of the devices described herein may further include operations, features, components, or instructions for generating a third hash of third data based on receiving a third command, and storing the third hash of the third data to a volatile memory component of a memory device based on generating the third hash.

[0111] Method 800 and some instances of the apparatus described herein may further include operations, features, components, or instructions for comparing a third hash of third data with a second hash associated with a second software image based on storing a third hash of third data to a volatile memory component, wherein verifying the second software image includes determining whether the third hash of the third data is identical to the second hash associated with the second software image based on comparing the third hash of the third data with the second hash associated with the second software image.

[0112] Method 800 and some examples of the devices described herein may further include generating a notification to avoid verifying a second software image based on determining that a third hash of third data may be different from a second hash, and transmitting the notification to an operation, feature, component, or instruction of a host system, wherein the notification contains an indication that the third data may be different from the second hash.

[0113] In some instances of method 800 and the devices described herein, verifying the second software image may include operations, features, components, or instructions for issuing a fourth command based on a third hash match of the third data associated with a second hash of the second software image, wherein the fourth command includes instructions to initiate a startup sequence.

[0114] Method 800 and some instances of the devices described herein may further include issuing a fourth command to avoid verifying operations, features, components, or instructions of the second software image based on determining that a third hash of third data may be different from a second hash associated with the second software image, wherein the fourth command includes instructions to avoid initiating a startup sequence.

[0115] In some instances of method 800 and the devices described herein, the second software image includes data indicating the differences between the first software image and the second software image.

[0116] In some instances of method 800 and the devices described herein, the calculated hash of the first hash may be stored in a volatile memory component of the memory device.

[0117] In some instances of method 800 and the devices described herein, the location of the first hash and the first data may be stored in a non-volatile memory component.

[0118] It should be noted that the methods described above describe possible implementations, and the operations and steps can be rearranged or otherwise modified, and other implementations are possible. Furthermore, portions of two or more of the methods may be combined.

[0119] The information and signals described herein can be represented using any of a variety of different techniques and skills. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced in the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles, or any combination thereof. Some illustrations may show a signal as a single signal; however, those skilled in the art will understand that the signal may represent a bus of signals, wherein the bus may have multiple bit widths.

[0120] The terms "electronic communication," "conductive contact," "connection," and "coupling" can refer to a relationship between components that supports the flow of signals between them. Components are considered to be in electronic communication (or in conductive contact, connection, or coupling) with each other if any conductive path exists between them that can support the flow of signals between them at any given time. At any given time, the conductive path between components that are in electronic communication (or in conductive contact, connection, or coupling) may be open or closed based on the operation of the device containing the connected component. The conductive path between connected components can be a direct conductive path between the components, or it can be an indirect conductive path that may include intermediate components such as switches, transistors, or other components. In some instances, the signal flow between connected components may be interrupted for a period of time, for example, using one or more intermediate components such as switches or transistors.

[0121] The term "coupling" refers to a condition that changes from an open-circuit relationship between components, where signals cannot currently travel between components via conductive paths, to a closed-circuit relationship where signals can travel between components via conductive paths. When a component, such as a controller, couples other components together, the component triggers a change that allows signals to flow between the other components via conductive paths that were previously not permitted.

[0122] The term "isolation" refers to the relationship between components in which signals are currently unable to flow between them. Components are isolated from each other if there is an open circuit between them. For example, two components separated by a switch positioned between them are isolated from each other when the switch is open. When a controller isolates two components, the controller affects the change that prevents signals from flowing between the components using previously permitted conductive paths.

[0123] The device comprising the memory array discussed herein can be formed on a semiconductor substrate, such as silicon, germanium, silicon-germanium alloy, gallium arsenide, gallium nitride, etc. In some instances, the substrate is a semiconductor wafer. In other instances, the substrate may be an epitaxial layer of semiconductor material on a substrate such as silicon on glass (SOG) or silicon on sapphire (SOP), or a silicon-on-insulator (SOI) substrate, or another substrate. The conductivity of the substrate or a subregion of the substrate can be controlled by doping with various chemicals including, but not limited to, phosphorus, boron, or arsenic. Doping can be performed during the initial formation or growth of the substrate by ion implantation or by any other doping method.

[0124] The switching components or transistors discussed herein may represent field-effect transistors (FETs) and include three-terminal devices comprising a source, drain, and gate. Terminals may be connected to other electronic components via a conductive material (e.g., a metal). The source and drain may be conductive and may comprise heavily doped (e.g., degenerate) semiconductor regions. The source and drain may be separated by lightly doped semiconductor regions or channels. If the channel is n-type (i.e., most carriers are electrons), then the FET may be called an n-type FET. If the channel is p-type (i.e., most carriers are holes), then the FET may be called a p-type FET. The channel may be covered by an insulating gate oxide. The conductivity of the channel can be controlled by applying a voltage to the gate. For example, applying a positive or negative voltage to an n-type FET or a p-type FET, respectively, makes the channel conductive. When a voltage greater than or equal to the transistor's threshold voltage is applied to the transistor's gate, the transistor may be "on" or "on". When a voltage less than the transistor's threshold voltage is applied to the transistor's gate, the transistor may be "off" or "off-start".

[0125] The descriptions herein, illustrated with reference to the accompanying drawings, depict exemplary configurations and do not represent all instances that may be implemented or that are within the scope of the claims. The term "exemplary" as used herein means "serving as an example, illustration, or description" and does not imply "preferred" or "superior to other instances." Specific details are included to provide an understanding of the described techniques. However, these techniques may be practiced without these specific details. In some cases, well-known structures and apparatuses are shown in block diagram form to avoid obscuring the concepts of the described instances.

[0126] In the accompanying drawings, similar components or features may have the same reference numerals. Additionally, various components of the same type may be distinguished by using a dash followed by a second reference numeral to differentiate them among similar components. If only the first reference numeral is used in the specification, the description applies to any of the similar components that have the same first reference numeral but are independent of the second reference numeral.

[0127] The information and signals described herein can be represented by any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced in the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles, or any combination thereof.

[0128] The various illustrative blocks and components described in this disclosure may be implemented or performed by a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but alternatively, the processor may be any processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration).

[0129] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored as one or more instructions or code on or transmitted via a computer-readable medium. Other examples and implementations are within the scope of this disclosure and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Features implementing the functions may also be physically located in various locations, including distributed so that portions of the functions are implemented in different physical locations. Additionally, as used herein (included in the claims), “or” when used in a list of items (e.g., a list of items ending with phrases such as “at least one of” or “one or more of”) indicates an inclusive list, such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Furthermore, as used herein, the phrase “based on” should not be considered a reference to a set of closing conditions. For example, without departing from the scope of this disclosure, an exemplary step described as "based on condition A" may be based on both condition A and condition B. In other words, as used herein, the phrase "based on" should be interpreted in the same way as the phrase "at least partially based on".

[0130] Computer-readable media includes both non-transitory computer storage media and communication media, with communication media encompassing any media that facilitates the transfer of a computer program from one place to another. Non-transitory storage media can be any available media accessible using a general-purpose or special-purpose computer. By way of example, and not limitation, non-transitory computer-readable media may include RAM, ROM, electrically erasable programmable read-only memory (EEPROM), optical disc (CD) ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other non-transitory media that can be used to carry or store desired program code components in the form of instructions or data structures and is accessible by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Furthermore, any connection is appropriately referred to as computer-readable media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave are included in the definition of media. As used herein, disks and optical discs include CDs, laser discs, optical discs, digital multifunction discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of these also fall within the scope of computer-readable media.

[0131] The description herein is provided to enable those skilled in the art to make or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method comprising: Receive a first software image and a first command to store the first software image in a memory device; The first hash of the first software image is generated at least in part based on the first data associated with the first software image and the first command; The first hash is stored in the non-volatile memory component of the memory device, at least in part based on the generation of the first hash; Receive a second software image at least partially based on the first software image and a second command to store the second software image in the memory device; A second hash associated with the second software image is generated, at least in part based on the first hash of the first software image and the second command; At least in part based on the generation of the second hash, a first indication of the relationship between the second software image and the first software image is stored in the non-volatile memory component of the memory device; as well as The second software image is verified by comparing the second hash with a third hash of the third data, which is generated at least in part based on the first hash and third data associated with the second software image, to determine whether the third hash of the third data is the same as the second hash associated with the second software image.

2. The method according to claim 1, further comprising: The first indication of the relationship between the second software image and the first software image is generated at least in part based on receiving the second software image, wherein storing the second hash and the first indication is at least in part based on generating the first indication.

3. The method according to claim 1, further comprising: The first hash to be used to generate the second hash is selected at least in part based on the relationship between the second software image and the first software image, wherein generating the second hash is at least in part based on the selection of the first hash.

4. The method of claim 1, further comprising: The first command for storing the first hash, storing the second hash, or both is received at least in part based on the generation of the second hash; as well as The third data is identified at least in part based on receiving the first command, wherein the third data includes data contained in the second data associated with the second software image but not contained in the first data.

5. The method of claim 1, further comprising: Receive an erase command to erase the second hash; as well as The first indication of the relationship between the second hash and the second software image stored in the non-volatile memory component is erased, at least in part, based on receiving the erase command.

6. The method of claim 5, further comprising: Before erasing the second hash and the first indication of the relationship between the second software image and the first software image, erase one or more additional hashes and indications of the correspondence between the additional hashes and the second software image.

7. The method of claim 1, further comprising: Identify changes in second data associated with the second software image relative to the first data; as well as The first indication of the relationship between the second software image and the first software image is updated at least in part based on identifying the changes in the second data.

8. The method of claim 1, wherein multiple hashes of the multiple software images stored in the non-volatile memory component are inaccessible by the host system.

9. The method of claim 1, further comprising: The memory device receives a third command for determining whether second data associated with the second software image has been modified, wherein the third command includes the first indication of the relationship between the second software image and the first software image.

10. The method of claim 9, further comprising: The third hash of the third data is generated at least in part based on receiving the third command; as well as The third hash of the third data is stored in the volatile memory component of the memory device, at least in part based on the generation of the third hash.

11. The method of claim 10, further comprising: The comparison is made, at least in part, between the third hash of the third data and the second hash associated with the second software image, based on storing the third hash of the third data into the volatile memory component.

12. The method of claim 11, further comprising: At least in part based on the determination that the third hash of the third data is different from the second hash, a notification is generated to avoid verifying the second software image, wherein the notification includes an indication that the third data is different from the second hash; as well as The notification is transmitted to the host system.

13. The method of claim 11, wherein verifying the second software image comprises: A fourth command is issued at least in part based on the determination that the third hash of the third data matches the second hash associated with the second software image, wherein the fourth command includes instructions to initiate a startup sequence.

14. The method of claim 11, further comprising: Based at least in part on the determination that the third hash of the third data is different from the second hash associated with the second software image, a fourth command is issued to avoid verifying the second software image, wherein the fourth command includes an instruction to avoid initiating a startup sequence.

15. The method of claim 1, wherein the second software image includes data indicating the difference between the first software image and the second software image.

16. The method of claim 1, wherein the third hash is stored in the volatile memory component of the memory device.

17. The method of claim 1, wherein the location of the first hash and the first data is stored in the non-volatile memory component.

18. A system comprising: A memory array used to store data associated with one or more software images; as well as A security component, coupled to the memory array and configured to verify at least one of the one or more software images, is configured to: A first command is given to receive a first software image and store the first software image in a memory device. The first hash of the first software image is generated at least in part based on the first data associated with the first software image and the first command; The first hash is stored in the security component at least in part based on the generation of the first hash; Receive a second software image at least partially based on the first software image and a second command to store the second software image in the memory device; A second hash associated with the second software image is generated, at least in part based on the first hash of the first software image and the second command; The security component stores, at least in part, a first indication of the relationship between the second hash and the second software image and the first software image, based on the generation of the second hash. as well as The second software image is verified by comparing the second hash with a third hash of the third data, which is generated at least in part based on the first hash and third data associated with the second software image, to determine whether the third hash of the third data is the same as the second hash associated with the second software image.

19. The system of claim 18, wherein the security component is configured to: The first indication is generated at least in part based on receiving the second software image to determine the relationship between the second software image and the first software image, wherein storing the second hash and the first indication is at least in part based on generating the first indication.

20. The system of claim 18, wherein the security component is configured to: The first hash to be used to generate the second hash is selected at least in part based on the relationship between the second software image and the first software image, wherein generating the second hash is at least in part based on the selection of the first hash; The first command for storing the first hash, storing the second hash, or both is received at least in part based on the generation of the second hash; as well as The third data is identified at least in part based on receiving the first command, wherein the third data includes data contained in the second data associated with the second software image but not contained in the first data.

21. The system of claim 18, wherein the security component is configured to: Receive the erase command to erase the second hash; At least in part based on receiving the erase command, the first indication of the relationship between the second hash and the second software image stored in the non-volatile memory component is erased; and Before erasing the second hash and the first indication of the relationship between the second software image and the first software image, erase one or more additional hashes and indications of the correspondence between the additional hashes and the second software image.

22. The system of claim 18, wherein the security component is configured to: The third hash that generates the third data; The comparison is made, at least in part, between the third hash of the third data and the second hash associated with the second software image, based on storing the third hash of the third data into a volatile memory component; A notification is generated at least in part based on the determination that the third hash of the third data is different from the second hash, wherein the notification includes an indication that the third data is different from the second hash; as well as The notification is transmitted to the host system.

23. The system of claim 18, wherein the security component is configured to: The third hash that generates the third data; At least in part, the third hash of the third data is compared with the second hash associated with the second software image by storing the third hash of the third data into a volatile memory component; and A third command is issued to the host system based at least in part on the determination that the third hash of the third data is different from the second hash associated with the second software image, wherein the third command includes instructions to avoid initiating a startup sequence.

24. A non-transitory computer-readable medium storing computer-executable code, said code being executable by a processor to perform the following operations: The first hash of the first software image is generated at least in part based on first data and a first command associated with the first software image; The first hash is stored in a non-volatile memory component, at least in part based on the generation of the first hash; Receive a second software image at least partially based on the first software image and a second command to store the second software image; A second hash associated with the second software image is generated, at least in part based on the first hash of the first software image and the second command; The second hash and a first indication of the relationship between the second software image and the first software image are stored in the non-volatile memory component, at least in part based on the generation of the second hash. as well as The second software image is verified by comparing the second hash with a third hash of the third data, which is generated at least in part based on the first hash and third data associated with the second software image, to determine whether the third hash of the third data is the same as the second hash associated with the second software image.

Images