Dynamic command extension for memory subsystem

Abstract

The processing device is configured to process an initial set of command types. A command extension module and a digital signature are received. The digital signature is generated based on the command extension module using a private key of a key pair. The command extension module, when installed by the processing device, enables the processing device to process new command types not included in the initial set of command types. The digital signature is verified using the public key of the key pair. Based on successful verification of the digital signature, the command extension module is temporarily installed by loading the command extension module into a volatile memory device.

Description

[Technical Field]

[0001] Priority application This application claims the benefit of priority to U.S. Application No. 16 / 749,558, filed January 22, 2020, which is incorporated herein by reference in its entirety.

[0002] FIELD Embodiments of the present disclosure relate generally to memory subsystems, and more particularly to dynamic expansion of memory subsystem commands. [Background technology]

[0003] A memory subsystem may include one or more memory devices for storing data. The memory devices may be, for example, non-volatile and volatile memory devices. Generally, a host system may utilize the memory subsystem to store data in and retrieve data from the memory devices.

[0004] The present disclosure will be more fully understood from the following detailed description and accompanying drawings of various embodiments of the disclosure. [Brief explanation of the drawings]

[0005] [Figure 1] 1 illustrates an exemplary computing environment including a memory subsystem, in accordance with some embodiments of the present disclosure. [Figure 2A] FIG. 1 is a data flow diagram illustrating interactions between components in a secure communication environment when performing an exemplary method for dynamic expansion of memory subsystem commands, according to some embodiments of the present invention. [Figure 2B] FIG. 1 is a data flow diagram illustrating interactions between components in a secure communication environment when performing an exemplary method for dynamic expansion of memory subsystem commands, according to some embodiments of the present invention. [Figure 2C]FIG. 1 is a data flow diagram illustrating interactions between components in a secure communication environment when performing an exemplary method for dynamic expansion of memory subsystem commands, according to some embodiments of the present invention. [Figure 3] 1 is a flow diagram illustrating an example method for dynamic expansion of memory subsystem commands, according to some embodiments of the present disclosure. [Figure 4] 1 is a flow diagram illustrating an example method for dynamic expansion of memory subsystem commands, according to some embodiments of the present disclosure. [Figure 5] FIG. 1 is a block diagram of an exemplary computer system on which embodiments of the present disclosure may operate. DETAILED DESCRIPTION OF THE INVENTION

[0006] Aspects of the present disclosure are directed to secure command extensions in a memory subsystem. The memory subsystem may be a storage device, a memory module, or a hybrid of a storage device and a memory module. Examples of storage devices and memory modules are described below in connection with FIG. 1. Generally, a host system may utilize a memory subsystem that includes one or more components, such as a memory device that stores data. The host system may provide data to be stored in the memory subsystem and may request data to be retrieved from the memory subsystem.

[0007] Typically, a memory subsystem controller receives commands or operations from a host system and translates the commands or operations into instructions or appropriate commands to achieve desired access to memory components of the memory subsystem. Typically, a memory subsystem is initially configured with firmware capable of supporting a set of command types that enable specific functionality for the memory subsystem. In some examples, these command types include vendor-specific command types that enable functionality that may be specific to a vendor's system configuration or process. However, each command type may provide an attack vector that can be exploited to gain unauthorized access to data stored by the memory subsystem. Furthermore, certain vendor-specific commands may create security vulnerabilities that can be exploited to gain unauthorized access.

[0008] Memory subsystem firmware is typically verified by the memory subsystem before installation to ensure that the firmware originates from a trusted source. As an example, the public key of an asymmetric key pair may be provisioned into the memory subsystem by the original equipment manufacturer (OEM) before shipment, while the corresponding private key is protected by a hardware security module (HSM) in a secure system external to and independent of the memory subsystem (e.g., operated by the OEM). The firmware is digitally signed with the private key to establish a root of trust, and the corresponding public key is used by the memory subsystem to verify the digital signature before installation.

[0009] In some examples, it may be desirable to extend the functionality of a memory subsystem beyond that enabled by the set of command types that the memory subsystem firmware can initially support. That is, it may be desirable to enable the memory subsystem to process additional command types that were not included in the original set of command types that the original memory subsystem firmware could process. In one example, it may be desirable to initially configure the memory subsystem to not use any vendor-specific commands, thereby reducing the attack vectors of the system, and later add the ability to process vendor-specific commands to the system. As another example, it may be desirable to temporarily provide specific functionality for debugging the memory subsystem.

[0010] Conventional techniques for command expansion in memory subsystems require downloading an updated firmware file that contains functionality for processing the additional commands, and the memory subsystem also requires the updated firmware file to be revalidated before installation. However, updated firmware files can be large, and downloading and revalidating can consume significant amounts of time and memory resources.

[0011] Aspects of the present disclosure include , Me of the memory subsystem Dynamic The above and other problems are addressed in a system and method for command extension. The above-mentioned command extension method requires the following: Complete installation of the new firmware package and, and 、 Reevaluate your firmware 、 It is dynamic in that the ability to process additional commands can be temporarily added to the memory subsystem without requiring

[0012] Consistent with some embodiments, the command processing component can add to the memory subsystem the ability to process command types that the memory subsystem cannot initially process. To extend the commands of the memory subsystem, the host system may provide a command extension module to the memory subsystem rather than an entire firmware package, which would also need to be reverified. Consistent with some embodiments, the command extension module itself may be subject to some form of access control to ensure secure access and prevent unauthorized access. For example, the command extension module may be password protected, and the host system may be required to provide a password to be able to download the command extension module. The command extension module is provided with a digital signature that is verified by the command processing component before temporarily installing the command extension module on the controller. Commands received by the command processing component that correspond to command types processed by the command extension module are forwarded to the command extension module, which processes the commands. The command extension module is installed only temporarily, in that it is loaded into a volatile memory device and therefore lost upon system reboot or expiration of a time-to-live (TTL) value associated with the command extension module.

[0013] The techniques for dynamic command extension described above reduce the vulnerability of memory subsystems by eliminating the need for firmware to process vendor-specific command types or command types whose need was not recognized at the time the firmware was created. Furthermore, such methods of dynamic command extension allow firmware to process only a limited set of command types, while the ability to process additional claim types can be added later. Reducing the number of command types also reduces the number of attack vectors that may be used to gain unauthorized access to the memory subsystem, thereby providing additional security benefits.

[0014] 1 illustrates an exemplary computing system 100 including a memory subsystem 110, in accordance with some embodiments of the present disclosure. Memory subsystem 110 may include media such as one or more volatile memory devices (e.g., memory device 140), one or more non-volatile memory devices (e.g., memory device 130), or a combination of the like.

[0015] The memory subsystem 110 can be a storage device, a memory module, or a hybrid of a storage device and a memory module. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controller (eMMC) drives, universal flash storage (UFS) drives, secure digital (SD) cards, and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and various types of non-volatile dual in-line memory modules (NVDIMMs).

[0016] Computing system 100 may be a computing device such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (e.g., an aircraft, drone, train, automobile, or other means of transportation), an Internet of Things (IoT) enabled device, an embedded computer (e.g., one contained in a vehicle, industrial equipment, or networked commercial device), or any such computing device that includes memory and processing devices.

[0017] Computing system 100 may include a host system 120 coupled to one or more memory subsystems 110. In some implementations, host system 120 is coupled to different types of memory subsystems 110. Figure 1 shows an example of a host system 120 coupled to one memory subsystem 110. As used herein, "coupled to" or "coupled with" generally refers to a connection between components, which may be an indirect or direct communication connection (e.g., no intervening components), whether wired or wireless, including electrical, optical, magnetic, etc. connections.

[0018] Host system 120 may include a processor chipset and a software stack executed by the processor chipset. The processor chipset may include one or more cores, one or more caches, a memory controller (e.g., an NVDIMM controller), and a storage protocol controller (e.g., a PCIe controller, a SATA controller). Host system 120 uses memory subsystem 110, for example, to write data to and read data from memory subsystem 110.

[0019] The host system 120 may be coupled to the memory subsystem 110 via a physical host interface. Examples of physical host interfaces include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Universal Serial Bus (USB) interface, Fibre Channel, Serial Attached SCSI (SAS), Small Computer System Interface (SCSI), a double data rate (DDR) memory bus, a dual in-line memory module (DIMM) interface (e.g., a DIMM socket interface supporting double data rate (DDR)), an Open NAND Flash Interface (ONFI), double data rate (DDR), low power double data rate (LPDDR), or any other interface. The physical host interface can be used to transfer data between the host system 120 and the memory subsystem 110. When the memory subsystem 110 is coupled to the host system 120 via a PCIe interface, the host system 120 can further utilize an NVM Express (NVMe) interface to access components (e.g., memory device 130). The physical host interface may provide an interface for passing control, address, data, and other signals between memory subsystem 110 and host system 120. Figure 1 illustrates memory subsystem 110 by way of example. In general, host system 120 may access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0020] Memory devices 130, 140 may include any combination of different types of non-volatile and / or volatile memory devices. Volatile memory devices (e.g., memory device 140) may be random access memories (RAMs), such as, but not limited to, dynamic random access memories (DRAMs) and synchronous dynamic random access memories (SDRAMs).

[0021] Some examples of nonvolatile memory devices (e.g., memory device 130) include write-in-place memories such as non-conjunction (NAND) flash memory and three-dimensional cross-point ("3D cross-point") memory devices, which are cross-point arrays of nonvolatile memory cells. Cross-point arrays of nonvolatile memory, in combination with stackable cross-grid data access arrays, can perform bit storage based on changes in bulk resistance. Furthermore, in contrast to many flash-based memories, cross-point nonvolatile memory can perform in-place write operations that allow the nonvolatile memory cells to be programmed without first erasing them. NAND flash memories include, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

[0022] Each of the memory devices 130 may include one or more arrays of memory cells. Other types of memory cells, such as multi-level cell (MLC), triple-level cell (TLC), and quad-level cell (QLC), can store multiple bits per cell. In some embodiments, each of the memory devices 130 may include one or more arrays of memory cells, such as SLC, MLC, TLC, QLC, or any combination of the above. In some embodiments, a particular memory device may include an SLC portion of memory cells and an MLC, TLC, or QLC portion of memory cells. The memory cells of the memory devices 130 may be grouped into pages, which may refer to logical units of a memory device used to store data. In some types of memory (e.g., NAND), pages may be grouped to form blocks.

[0023] Although non-volatile memory components such as NAND-type flash memory (e.g., 2D NAND, 3D NAND) and 3D cross-point arrays of non-volatile memory cells are described, the memory device 130 may be based on any other type of non-volatile memory, such as read-only memory (ROM), phase-change memory (PCM), self-selection memory, other chalcogenide-based memory, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), spin-transfer magnetization reversal (STT) MRAM, conductive bridge RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), negative-or (NOR) flash memory, and electrically erasable programmable read-only memory (EEPROM).

[0024] Memory subsystem controller 115 (or, for simplicity, controller 115) can communicate with memory device 130 to perform operations such as reading data, writing data, or erasing data in memory device 130, and other such operations. Memory subsystem controller 115 can include hardware such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. Hardware can include digital circuitry with dedicated (i.e., hard-coded) logic for performing the operations described herein. Memory subsystem controller 115 can be a microcontroller, a dedicated logic circuit (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or other suitable processor.

[0025] The memory subsystem controller 115 may include a processor 117 (e.g., a processing device) configured to execute instructions stored in a local memory 119. In the illustrated example, the local memory 119 of the memory subsystem controller 115 includes an embedded memory configured to store instructions for executing routines that control the operation of the memory subsystem 110, including handling various processes, operations, logic flows, and communications between the memory subsystem 110 and the host system 120.

[0026] In some embodiments, local memory 119 may include memory registers that store memory pointers, fetched data, etc. Local memory 119 may also include read-only memory (ROM) for storing microcode. While the example memory subsystem 110 of FIG. 1 is shown as including a memory subsystem controller 115, in other embodiments of the present disclosure, memory subsystem 110 may not include a memory subsystem controller 115 and instead rely on external control (e.g., provided by an external host or by a processor or controller separate from the memory subsystem).

[0027] Generally, memory subsystem controller 115 can receive commands or operations from host system 120 and translate the commands or operations into instructions or appropriate commands to achieve desired access to memory device 130 and / or memory device 140. Memory subsystem controller 115 can be responsible for other operations, such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, caching operations, and address translation between logical addresses (e.g., logical block addresses (LBAs), namespaces) and physical addresses (e.g., physical block addresses), associated with memory device 130. Memory subsystem controller 115 can further include host interface circuitry for communicating with host system 120 via a physical host interface. The host interface circuitry can translate commands received from the host system into command instructions for accessing memory device 130 and / or memory device 140 and translate responses associated with memory device 130 and / or memory device 140 into information for host system 120.

[0028] Memory subsystem 110 may also include additional circuits or components not shown. In some embodiments, memory subsystem 110 may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row decoder and column decoder) that can receive addresses from memory subsystem controller 115 and decode the addresses to access memory devices 130.

[0029] In some embodiments, memory device 130 includes a local media controller 135 that operates in conjunction with memory subsystem controller 115 to perform operations on one or more memory cells of memory device 130. An external controller (e.g., memory subsystem controller 115) can externally manage memory device 130 (e.g., perform media management operations on memory device 130). In some embodiments, memory device 130 is a managed memory device, which is a raw memory device combined with a local controller (e.g., local controller 135) for media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

[0030] Command processing component 113 of controller 115 receives commands sent by host system 120 via the physical host interface. Command processing component 113 may be included in controller 115 or in any one or more of memory devices 130 or 140. In some embodiments, controller 115 includes at least a portion of command processing component 113. For example, controller 115 may include processor 117 (a processing device) configured to execute instructions stored in local memory 119 to perform the operations described herein.

[0031] Initially, the controller 115 may be configured (e.g., by firmware installed by the manufacturer) to process only a limited set of command types previously determined, for example, by the manufacturer of the controller 115. The command processing component 113 of the controller is configured to allow dynamic expansion of commands. That is, the command processing component 113 can add the ability to process additional command types to the controller 115. To expand the commands of the controller 115, the host system 120 provides a command expansion module to the controller 115. The command expansion module, when installed, includes a set of machine-readable instructions that enables the controller 115 to process at least one new command type that is not included in the set of predetermined command types that the command processing component 113 has enabled the controller 115 to process. The command expansion module is provided with a digital signature that is verified by the command processing component 113 before temporarily installing the command expansion module on the controller 115. For example, the command processing component 113 may load the command expansion module into a volatile memory device (e.g., memory device 130). In this manner, the installation of a command extension module is temporary, as the command extension module is lost upon reboot of memory subsystem 110. In some embodiments, a command extension module may be erased from memory based on the expiration of a TTL value associated with the module.

[0032] If command processing component 113 determines that a command received from host system 120 corresponds to a command type that an installed command extension module is configured to process, extension redirection component 114 of command processing component 113 redirects (forwards) the command to the command extension module, which processes the command accordingly.

[0033] 2A-2C are data flow diagrams illustrating interactions between components in a secure communication environment when performing an exemplary method for dynamic expansion of memory subsystem commands according to some embodiments of the present invention.

[0034] 2A and 2C, an asymmetric cryptographic key pair—public key 200 and private key 201—may be pre-generated and command processing component 113 may be provisioned with public key 200, while private key 201 is maintained in a separate, secure environment (e.g., including one or more processors). Command processing component 113 stores public key 200 in key store 202. Key store 202 may be implemented within any one or more of the non-volatile memory devices (e.g., local memory 119) or memory devices 140 of controller 115.

[0035] As shown, command processing component 113, in some embodiments, may be included as part of verified firmware 203 installed on controller 115. Firmware 203 includes a set of machine-readable instructions that may be executed by controller 115 to perform certain functions. For example, firmware 203 enables controller 115 to process a set of predefined command types received from host system 120. As described above, host system 120 may send commands to controller 115 via its host interface. Commands corresponding to one of the set of predefined command types are processed by command processing component 113. Firmware 203 is verified in that it is digitally signed using private key 201, and the digital signature is verified by controller 115 using public key 200. For example, as shown, digital signature 204 generated based on firmware 203 using private key 201 is provided with firmware 203, and controller 115 verifies digital signature 204 using public key 200.

[0036] To extend the capabilities of controller 115 to process one or more additional commands, user 205 of host system 120 causes host system 120 to send a command extension request to controller 115. The command extension request includes a command extension module 206 and a digital signature 207. Command extension module 206 includes a set of machine-readable instructions that, when installed by controller 115, enables controller 115 to process at least one new command type that is not included in the set of predefined command types that firmware 203 enables controller 115 to process. Digital signature 207 is generated based on command extension module 206 using private key 201. In some embodiments, a security version of extension module 206 is included in the command extension request. For example, the security version may be specified in a field of extension module 206 or otherwise in a field of the command extension request.

[0037] The command processing component 113 receives the command extension request and verifies the digital signature 207 to ensure that the extension module 206 is provided by a trusted source. The command processing component 113 verifies the digital signature 207 using the public key 200. In one example, the digital signature 207 may be generated by creating a first hash based on the extension module 206, and the first hash may be encrypted using the private key 201 to generate the digital signature 207. To verify the digital signature 207, the command processing component 113 generates a second hash based on the received extension module 206 and decrypts the digital signature 207 to generate the first hash. The command processing component 113 compares the first hash and the second hash, and if they match, the digital signature 207 is valid. If the first hash and the second hash do not match, the command processing component 113 determines that the digital signature 207 is not valid, and the command extension request is rejected.

[0038] 2B, expansion module 206 is temporarily installed in controller 115 based at least in part on successful verification of digital signature 207. In this way, the commands of controller 115 can be expanded beyond their initial capabilities without having to provide updated firmware packages to controller 115 and verify the updated firmware packages, which may be much larger in size than expansion module 206.

[0039] In some embodiments, the command processing component 113 may verify the security version of the extension module 206 before installation. The security version is used for anti-rollback support (e.g., to prevent a validly signed extension module from being installed on a device). For example, the command processing component 113 may maintain a security version counter to track the command extension modules installed on the controller 115 and may verify the security version of the extension module 206 by performing a comparison of the security version with the security version counter. If the security version of the downloaded and verified command extension module is greater than or equal to a stored security version counter value maintained by the command processing component 113 (e.g., in the NVM of the memory subsystem controller 115, such as local memory 119), then the downloaded command extension module may be installed and used. Otherwise, if the module's security version is less than the stored security version, the command extension module is rejected by the command processing component 113. Once the command extension module is accepted, the command processing component 113 updates (e.g., increments) the stored security version value if the security version of the command extension module exceeds the currently stored value.

[0040] In various other embodiments, a TTL value may be used in addition to or instead of a security version counter to control the lifetime of a command extension module. That is, a command extension module may contain a TTL value, and once the command extension module is downloaded and verified, the TTL counter begins counting down. When the TTL counter reaches zero, the command extension module may be erased from device memory and a new extension module must be downloaded.

[0041] 2B , the host system 120 may send a command to the controller 115 (e.g., based on input from the user 205). The extended redirection component 114 parses the command and determines that the command corresponds to a command type that the extension module 206 can and is responsible for processing. Based on determining that the extended command corresponds to a new command type associated with the extension module 206, the extended redirection component 114 redirects the command to the extension module 206, which then processes the command. In processing the command, the extension module 206 may perform one or more callbacks to the firmware 203 to invoke functions provided by the firmware 203.

[0042] The expansion module 206 is temporarily installed in the controller 115 because the expansion module 206 is stored in a volatile memory device (e.g., memory device 130) and therefore the expansion module 206 is erased upon reboot of the memory subsystem 110. For example, as shown in FIG. 2C , the expansion module 206 is no longer loaded into the controller 115 after a reboot. In another example, the expansion module 206 may be erased based on the expiration of a TTL value associated with the expansion module 206. As described above, the command processing component 113 cannot reinstall the expansion module 206 because the security version of the expansion module 206 no longer corresponds to the security version counter maintained by the command processing component 113.

[0043] 3 and 4 are flow diagrams illustrating an example method 300 for dynamic expansion of memory subsystem commands in accordance with some embodiments of the present disclosure. Method 300 may be performed by processing logic, which may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, device hardware, integrated circuits, etc.), software (e.g., instructions run on or executed by a processing device), or a combination thereof. In some embodiments, method 300 is performed by command processing component 113 of FIG. 1. Although processes are shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes can be performed in a different order, and some processes can be performed in parallel. Furthermore, in various embodiments, one or more processes can be omitted. Thus, not all processes are required in all embodiments. Other process flows are possible.

[0044] Prior to method 300, an asymmetric public / private key pair—a public key and a private key—is pre-generated, and the processing device receives the public key. of May be provisioned or otherwise to The public key may be accessible while the private key is maintained in a separate, different, secure environment (e.g., operated by the OEM). Additionally, the processing device includes firmware that enables the processing device to process a predetermined set of command types.

[0045] In operation 305, the processing device receives a command extension module and a digital signature as part of the command extension request. The command extension module includes a set of machine-readable instructions that enable the processing device to process at least one new command type that is not included in the set of predetermined command types that the firmware enables the processing device to process. The digital signature is generated based on the command extension module using a private key. Signing the command extension module with the cryptographic signature may occur in a remote, secure environment. The digital signature may include an asymmetric cryptographic signature generated using a cryptographic algorithm such as the Rivest-Shamir-Adelman (RSA) algorithm. The cryptographic signature may be associated with a public key that can be shared with one or more devices and a private key that can be shared with a limited number of devices. The combination of the public and private keys can be used to verify the integrity of the command extension module using an asymmetric cryptographic algorithm. Consistent with some embodiments, the command extension module may also be encrypted, for example, using a symmetric cryptographic algorithm (e.g., Advanced Encryption Standard (AES)).

[0046] The command extension request may be received from host system 120. In some embodiments, receiving the request includes receiving one or more commands from the host system via a host system interface. In some embodiments, receiving the request includes receiving the request from the host system via a communications port (e.g., a UART port or other serial communications port supporting bidirectional communications). In some embodiments, an out-of-band interface can be used to exchange data between host system 120 and a processing device (e.g., a system management bus (SMBus) or an inter-integrated circuit (I2C) bus).

[0047] The processing device verifies the digital signature in operation 310 using the public key that corresponds to the private key. As described above, the processing device has previously been provisioned with a public key. The public key may be stored in a key store (e.g., key store 202) maintained in a non-volatile memory device (e.g., local memory 119 or memory device 140). The combination of the public key and the private key can be used to verify the digital signature based on one or more cryptographic procedures. For example, the digital signature may be an asymmetric cryptographic signature that can be verified based on an asymmetric cryptographic procedure that uses an asymmetric cryptographic algorithm (e.g., RSA) used to generate the signature.

[0048] In response to successful verification of the digital signature, the processing device temporarily installs the command extension module in operation 315. Installing the command extension module includes storing the command extension module in a volatile memory device (e.g., memory device 130). In this manner, the installation of the command extension module is not persistent, as the command extension module is lost upon system reboot or expiration of the TTL value.

[0049] In operation 320, the processing device receives the command and determines that the command corresponds to a command type that the command extension module can process in operation 325. The command may be received from the host system 120 via the host interface.

[0050] In response to determining that the command corresponds to a command type that the command extension module can process, the processing device forwards the extended command to the command extension module in operation 330. More specifically, the processing device may include an extension redirection component (e.g., extension redirection component 114) responsible for redirecting commands to the command extension module that the command extension module is responsible for processing. The extension redirection component may parse the command and determine that the command corresponds to a command type that the command extension module processes.

[0051] The command extension module processes the extended command in operation 335. The command extension module may perform one or more actions in processing the extended command. In some examples, the command extension module may perform one or more callbacks to the processing device for support functions needed to process the extended command.

[0052] 4, method 300, in some embodiments, may include operations 311, 312, and 316. Consistent with these embodiments, operations 311 and 312 may be performed before operation 315, in which the processing device temporarily installs the command extension module.

[0053] The processing device determines the security version of the command extension module in operation 311. The security version of the command extension module may be included, for example, in the command extension request in which the command extension module was included.

[0054] At operation 312, the processing device verifies the security version of the command extension module. The processing device verifies the security version of the command extension module based on stored information used to track command extension modules installed by the processing device. For example, the processing device may maintain a security version counter to track which command extension modules have been installed by the processing device. The processing device may compare the security version of the command extension module to the security version counter to determine whether the command extension module has been previously installed. If the command extension module has not been previously installed, the processing device successfully verifies the security version and installs the extension module based on the successful verification. If the command extension module has been previously installed, the processing device determines that the security version is invalid, and the processing device rejects the command extension request.

[0055] Consistent with these embodiments, operation 316 may be performed after operation 315. At operation 316, the processing device increments a security version counter based on the installation of the command extension module. As described above, the security version counter is used to track which command extension modules have been installed by the processing device. After updating the security version counter, the command extension module can no longer be installed by the processing device.

[0056] In various other embodiments, a TTL value may be used in addition to or instead of the security version counter. That is, a command extension module may specify a TTL value that is used to control the lifetime of the extension module. That is, once a command extension module is downloaded and verified, a TTL counter begins counting down. When the TTL counter reaches zero, the extension module is purged from device memory and a new extension module must be downloaded.

[0057] Example 1 is a system comprising: a volatile memory device having a volatile storage medium; and a processing device configured to process an initial set of command types, the processing device operably coupled to the volatile memory device to perform operations including: receiving a command extension module and a digital signature, the digital signature being generated based on the command extension module using a private key of a key pair, the command extension module, when installed by the processing device, enabling the processing device to process new command types not included in the initial set of command types; verifying the digital signature using a public key of the key pair; and based on successful verification of the digital signature, temporarily installing the command extension module on the system, the temporarily installing comprising loading the command extension module into the volatile memory device.

[0058] In Example 2, the subject matter of Example 1 optionally includes an extension redirection component to receive a command, determine that the command corresponds to the new command type, and forward the command to the command extension module based on the command's correspondence to the new command type.

[0059] In Example 3, the command extension module of any one or more of Examples 1 or 2 processes the command.

[0060] In Example 4, the command extension module of any one or more of Examples 1-3 performs one or more callbacks to the firmware when processing the command.

[0061] In Example 5, the command extension module of any one of Examples 1-4 is erased upon system reboot or when the TTL value expires.

[0062] In Example 6, the operations of any one or more of Examples 1-5 optionally include determining a security version of the command extension module and verifying the security version of the command extension module based on stored information.

[0063] In Example 7, the operation of any one or more of Examples 1-6 optionally includes verifying the security version of the command extension module by comparing the security version of the command extension module with a security version counter.

[0064] In Example 8, the operation of any one or more of Examples 1-7 optionally includes incrementing the security version counter based on temporarily installing the command extension module.

[0065] In Example 9, the subject matter of any one or more of Examples 1-8 optionally comprises a non-volatile storage medium for storing the public key.

[0066] In Example 10, the subject matter described in any one or more of Examples 1 to 9 optionally includes a host interface, and the command extension module and the digital signature are received via the host interface as part of a command extension request.

[0067] In Example 11, the operations of any one or more of Examples 1-10 optionally include using an asymmetric cryptographic algorithm to verify the digital signature based on a combination of the public key and the private key.

[0068] Example 12 is a method including receiving, by a memory subsystem controller comprising one or more processors of a machine, a command extension module and a digital signature, the digital signature being generated based on the command extension module using a private key of a key pair, the memory subsystem controller comprising firmware that enables the memory subsystem to process an initial set of command types, the command extension module including a set of machine-readable instructions that, when installed by the memory subsystem controller, enables the memory subsystem controller to process new command types not included in the initial set of command types; verifying, by the memory subsystem controller, the digital signature using a public key of the key pair; and based on successful verification of the digital signature, temporarily installing the command extension module at the memory subsystem controller, wherein the temporary installation of the command extension module includes storing the command extension module in a volatile memory device of the memory subsystem controller.

[0069] In Example 13, the subject matter of Example 1 optionally includes determining that the command corresponds to the new command type; and forwarding the command to the command extension module based on the command corresponding to the new command type.

[0070] In Example 14, the subject matter of any one or more of Examples 12 or 13 optionally includes processing the command using the extended command module.

[0071] In Example 15, the command extension module of any one of Examples 12-14 is erased upon system reboot.

[0072] In Example 16, the subject matter described in any one or more of Examples 12-15 optionally includes determining a security version of the command extension module and verifying the security version of the command extension module based on stored information.

[0073] In Example 17, the operations of any one or more of Examples 12-16 optionally include verifying the security version of the command extension module by comparing the security version of the command extension module with a security version counter, and incrementing the security version counter based on temporarily installing the command extension module.

[0074] In Example 18, the subject matter described in any one or more of Examples 12-17 optionally includes receiving the command extension module and the digital signature from a host system via a host interface as part of a command extension request.

[0075] In Example 19, the subject matter of any one or more of Examples 12-18 optionally includes using an asymmetric cryptographic algorithm to verify the digital signature based on a combination of the public key and the private key.

[0076] Example 20 is a non-transitory computer-readable storage medium containing instructions that, when executed by a processing device, configure a processing device to perform operations including: receiving a command extension module and a digital signature, the digital signature being generated based on the command extension module using a private key of a key pair, the processing device comprising firmware that enables the processing device to process an initial set of command types, the command extension module including a set of machine-readable instructions that, when installed by the processing device, enables the processing device to process new command types not included in the initial set of command types; verifying the digital signature using a public key of the key pair; and, based on successful verification of the digital signature, temporarily installing the command extension module, wherein the temporary installation of the command extension module includes storing the command extension module in a volatile memory device of the processing device.

[0077] FIG. 5 illustrates an exemplary machine in the form of a computer system 500, in which a set of instructions can be executed to cause the machine to perform any one or more of the methods described herein. In some embodiments, computer system 500 may correspond to a host system (e.g., host system 120 of FIG. 1) that includes, is coupled to, or utilizes a memory subsystem (e.g., memory subsystem 110 of FIG. 1) or can be used to perform operations of a controller (e.g., to execute an operating system to perform operations corresponding to command processing component 113 of FIG. 1). In alternative embodiments, the machine can be connected (e.g., networked) to other machines in a local area network (LAN), an intranet, an extranet, and / or the Internet. The machine can operate in the function of a server or a client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0078] The machine may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), mobile phone, web appliance, server, network router, switch or bridge, or any machine capable of executing (serially or otherwise) a set of instructions that specify actions to be taken by the machine. Further, although a single machine is shown, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or sets) of instructions to perform any one or more of the methodologies described herein.

[0079] The exemplary computer system 500 includes a processing device 502, a main memory 504 (e.g., ROM, flash memory, DRAM such as SDRAM or Rambus DRAM (RDRAM), etc.), a static memory 506 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system 518, which communicate with each other via a bus 530.

[0080] Processing device 502 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. More specifically, processing device 502 may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing other instruction sets, or a processor implementing a combination of instruction sets. Processing device 502 may also be one or more special-purpose processing devices, such as an ASIC, an FPGA, a digital signal processor (DSP), a network processor, or the like. Processing device 502 is configured to execute instructions 525 to perform the operations and steps described herein. Computer system 500 may further include a network interface device 508 for communicating over network 520.

[0081] Data storage system 518 may include a machine-readable storage medium 524 (also known as a computer-readable medium) having stored thereon one or more sets of instructions 525 or software that embody any one or more of the methods or functions described herein. The instructions 525 may also reside, completely or at least partially, within main memory 504 and / or processing device 502 during execution by computer system 500, main memory 504, and processing device 502, which constitute the machine-readable storage medium. The machine-readable storage medium 524, data storage system 518, and / or main memory 504 may correspond to memory subsystem 110 of FIG. 1.

[0082] In one embodiment, instructions 526 include instructions for implementing functionality corresponding to a security component (e.g., command processing component 113 of FIG. 1). While machine-readable storage medium 524 is shown in the exemplary embodiment to be a single medium, the term "machine-readable storage medium" should be interpreted to include a single medium or multiple media that store one or more sets of instructions. The term "machine-readable storage medium" should also be interpreted to include any medium capable of storing or encoding a set of instructions for execution by a machine, causing the machine to perform any one or more of the methods of the present disclosure. Accordingly, the term "machine-readable storage medium" should be interpreted to include, but is not limited to, solid-state memory, optical media, and magnetic media.

[0083] Some portions of the preceding detailed descriptions are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0084] It should be recognized, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. This disclosure may refer to the operations and processes of a computer system, or similar electronic computing device, that manipulate and convert data represented as physical (electronic) quantities in the computer system's registers and memory into other data also represented as physical quantities in the computer system's memory or registers or such information storage system.

[0085] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may include a general-purpose computer, which may be specially constructed for an intended purpose, or which is selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored on any type of computer-readable storage medium, including, but not limited to, a floppy disk, an optical disk, a CD-ROM, and a magneto-optical disk, a ROM, a RAM, an erasable programmable read-only memory (EPROM), an EEPROM, a magnetic or optical card, or any type of medium suitable for storing electronic instructions, each of which may be coupled to a computer system bus.

[0086] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems can be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the methods. A structure for a variety of these systems appears as set forth in the description above. Additionally, the present disclosure is not described with reference to any particular programming language. It will be understood that a variety of programming languages ​​can be used to implement the teachings of the present disclosure as described herein.

[0087] The present disclosure can be manifested as a computer program product or software, which can include a machine-readable medium having stored thereon instructions that can be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). In some embodiments, the machine-readable (e.g., computer-readable) medium includes a machine-readable (e.g., computer-readable) storage medium such as ROM, RAM, magnetic disk storage media, optical storage media, flash memory components, and the like.

[0088] In the foregoing specification, embodiments of the present disclosure have been described with reference to certain exemplary embodiments thereof. It will be apparent that various changes can be made therein without departing from the broader scope of the embodiments of the present disclosure as set forth in the following claims. The specification and drawings are, therefore, to be regarded in an illustrative rather than a restrictive sense.

Claims

1. a volatile memory device; a processing device configured to process an initial set of command types; 1. A memory subsystem comprising: the processing device receiving a command extension module and a digital signature, the digital signature being generated based on the command extension module using a private key of a key pair, the command extension module, when installed by the processing device, enabling the processing device to process new command types not included in the set of initial command types; verifying the digital signature using the public key of the key pair; determining whether the command extension module has been previously installed by checking a security version of the command extension module, the checking of the security version including comparing the security version of the command extension module to a security version counter maintained by the processing device for anti-rollback support that prevents a previously installed command extension module from being reinstalled in the memory subsystem; temporarily installing the command extension module in the memory subsystem based on successful verification of the digital signature and successful verification of the security version indicating that the command extension module has not been previously installed, wherein the temporarily installing of the command extension module includes loading the command extension module into the volatile memory device; incrementing the security version counter to indicate that the command extension module is installed, wherein in response to the incrementing of the security version counter, the processing device is unable to reinstall the command extension module; the memory subsystem operatively coupled with the volatile memory device to perform operations including:

2. the processing device: Receives the command determining that the command corresponds to the new command type; forwarding the command to the command extension module based on the command's correspondence to the new command type; 10. The memory subsystem of claim 1, comprising an enhanced redirection component for:

3. The memory subsystem of claim 2 , wherein the command extension module processes the command.

4. The memory subsystem of claim 3 , wherein the command extension module performs one or more callbacks to the processing device when processing the command.

5. 10. The memory subsystem of claim 1, wherein the command extension module is erased upon system reboot or upon expiration of a Time to Live (TTL) value.

6. The operation is Determining the security version of the command extension module The memory subsystem of claim 1 further comprising:

7. The memory subsystem of claim 1 further comprising a non-volatile storage medium for storing said public key.

8. 10. The memory subsystem of claim 1, further comprising a host interface, wherein the command extension module and the digital signature are received via the host interface as part of a command extension request.

9. 2. The memory subsystem of claim 1, wherein the verifying of the digital signature by the processing device includes using an asymmetric cryptographic algorithm to verify the digital signature based on a combination of the public key and the private key.

10. 1. A method comprising: receiving, by a memory subsystem controller comprising one or more processors of a machine, a command extension module and a digital signature, the digital signature being generated based on the command extension module using a private key of a key pair, the memory subsystem controller comprising firmware that enables the memory subsystem controller to process a set of initial command types, the command extension module including a set of machine-readable instructions that, when installed by the memory subsystem controller, enables the memory subsystem controller to process new command types not included in the set of initial command types; verifying, by the memory subsystem controller, the digital signature using the public key of the key pair; determining whether the command extension module has been previously installed by checking a security version of the command extension module, the checking of the security version including comparing the security version of the command extension module to a security version counter maintained by the memory subsystem controller for anti-rollback support that prevents a previously installed command extension module from being reinstalled on the system; temporarily installing the command extension module at the memory subsystem controller based on successful verification of the digital signature and successful verification of the security version indicating that the command extension module has not been previously installed, the temporary installation of the command extension module comprising storing the command extension module in a volatile memory device of the memory subsystem controller; incrementing the security version counter to indicate that the command extension module is installed, wherein in response to the incrementing of the security version counter, the processing device is unable to reinstall the command extension module; The method comprising:

11. Receiving a command; determining that the command corresponds to the new command type; forwarding, by a redirection component of the memory subsystem controller, the command to the command extension module based on the command corresponding to the new command type; The method of claim 10 further comprising:

12. The method of claim 11 , further comprising processing the command by the command extension module.

13. The method of claim 10 , wherein the command extension module is erased upon system reboot.

14. The method of claim 10 , further comprising determining the security version of the command extension module.

15. 15. The method of claim 14, further comprising incrementing the security version counter based on temporarily installing the command extension module.

16. 11. The method of claim 10, wherein the command extension module and the digital signature are received from a host system via a host interface of the memory subsystem controller as part of a command extension request.

17. 11. The method of claim 10, wherein the verifying the digital signature comprises using an asymmetric cryptographic algorithm to verify the digital signature based on a combination of the public key and the private key.

18. A non-transitory computer-readable storage medium containing instructions, The instructions, when executed by a processing device of a memory subsystem, receiving a command expansion module and a digital signature, the digital signature being generated based on the command expansion module using a private key of a key pair, the processing device comprising firmware that enables the processing device to process an initial set of command types, the command expansion module including a set of machine-readable instructions that, when installed by the processing device, enables the processing device to process new command types not included in the initial set of command types; verifying the digital signature using the public key of the key pair; determining whether the command extension module has been previously installed by checking a security version of the command extension module, the checking of the security version including comparing the security version of the command extension module to a security version counter maintained by the processing device for anti-rollback support that prevents a previously installed command extension module from being reinstalled in the memory subsystem; temporarily installing the command extension module based on successful verification of the digital signature and successful verification of the security version indicating that the command extension module has not been previously installed, wherein the temporary installation of the command extension module includes storing the command extension module in a volatile memory device of the processing device; incrementing the security version counter to indicate that the command extension module is installed, wherein in response to the incrementing of the security version counter, the processing device is unable to reinstall the command extension module; The non-transitory computer-readable storage medium, configuring the processing device to perform operations including:

Images