Dynamic Command Extension for Memory Sub-Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional techniques for extending memory sub-system commands require downloading and revalidating an entire firmware package, which is resource-intensive and vulnerable to security threats due to the need to process additional command types.
Innovation Solution
The implementation of a dynamic command extension method that allows a command processing component to temporarily add functionality to process additional command types without requiring a new firmware package, using a command extension module that is password-protected and digitally signed for secure access.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If conventional techniques are used to extend memory sub-system commands, then additional command types can be processed, but the entire firmware package must be downloaded and revalidated which consumes large amounts of time and memory resources
Solution Approach 1:
The firmware is segmented into a base firmware package and separate command extension modules. Each extension module contains functionality for specific additional command types, allowing selective loading rather than requiring complete firmware revalidation. This segmentation enables incremental updates and reduces the overhead of firmware management.
Solution Approach 2:
Command extension modules are pre-validated and digitally signed before being made available for loading. The validation process is performed in advance during module creation, so that when modules are loaded at runtime, they can be quickly verified through digital signature checking rather than undergoing complete revalidation. This preliminary action significantly reduces the time and resources required for command extension.
2Adaptability or versatility
If conventional techniques are used to extend memory sub-system commands, then additional command types can be processed, but the entire firmware package must be revalidated which consumes large amounts of memory resources
Solution Approach 1:
The firmware architecture is segmented into a stable base firmware residing in non-volatile memory and dynamic command extension modules that can be loaded into volatile memory as needed. This segmentation allows the system to maintain a minimal permanent footprint while loading only the necessary extension functionality into high-speed memory, reducing overall memory resource consumption.
Solution Approach 2:
Command extension modules are designed to be temporarily loaded into volatile memory, used to extend command processing capability, and then discarded or unloaded when no longer needed. This approach allows the system to recover memory resources by unloading extension modules, enabling dynamic memory management that adapts to varying operational requirements without permanently consuming large amounts of memory.
3Adaptability or versatility
If the memory sub-system processes additional command types, then functionality is extended, but security vulnerabilities increase due to more attack vectors
Solution Approach 1:
Command extension modules are pre-validated and digitally signed by trusted authorities before being made available for loading. The validation process includes security checks to ensure the module comes from a trusted source and has not been compromised. This preliminary anti-action prevents malicious or unauthorized code from being injected into the system, mitigating security risks before they can affect operation.
Solution Approach 2:
A secure intermediary validation mechanism is introduced between the command extension module and the memory sub-system. The digital signature verification process acts as an intermediary that mediates trust, ensuring that only authenticated and authorized extension modules can be loaded. This intermediary layer isolates the system from untrusted sources while still allowing legitimate functionality extensions, thereby reducing security vulnerabilities.
4Productivity
If a command extension module is temporarily installed, then new command types can be processed without full firmware update, but the system must verify digital signatures which adds processing overhead
Solution Approach 1:
Digital signatures are pre-computed and embedded in command extension modules during their creation process. The complex cryptographic operations required for signature generation are performed in advance during module development, not during system operation. This preliminary action shifts the computational burden to the module creation phase, allowing fast verification during deployment without significantly impacting runtime performance.
Solution Approach 2:
The public key used for verification is copied and stored in the memory sub-system during initial setup, while the private key remains securely stored elsewhere. This copying approach allows the system to perform fast local verification operations using the copied public key without needing to access the secure private key during runtime, reducing processing overhead while maintaining security.
Data Source
AI summary
A 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, once installed by the processing device, enables the processing device to process a new command type that is not included in the initial set of command types. The digital signature is verified using a public key of the key pair. Based on a successful verification of the digital signature, the command extension module is temporarily installed by loading the command extension module in a volatile memory device.