Secure Boot Memory Map Remapping for Flash Integrity
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Malicious code can compromise flash memory devices by being loaded into blocks, potentially altering critical applications and the operating system, and existing security measures may not adequately protect secure boot processes.
Innovation Solution
Implementing secure blocks in flash memory devices that are inaccessible during normal operations but can be mapped into the memory address range during initialization, allowing boot code to validate configuration settings and ensure integrity by executing from these secure blocks, which are remapped back to accessible blocks after initialization, preventing modifications during runtime.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If secure blocks are isolated during initialization, then boot code integrity is ensured, but accessibility to these blocks during normal operations is restricted
Solution Approach 1:
The flash memory device is divided into accessible blocks and secure blocks that are physically separated and logically isolated during initialization. The secure blocks contain boot code and are protected from access during normal operations, while accessible blocks can be freely accessed. This segmentation ensures boot code integrity while maintaining operational accessibility.
Solution Approach 2:
The memory map configuration is dynamic, allowing the system to switch between different access modes. During initialization, the memory map is configured to access secure blocks for boot code execution. During normal operations, the memory map is remapped to access only accessible blocks, preventing access to secure blocks. This dynamic remapping resolves the contradiction between integrity and accessibility.
2Adaptability or versatility
If memory addresses are mapped to EFA blocks during operations, then code execution from EFA blocks is enabled, but security risks increase due to potential malicious code execution
Solution Approach 1:
The boot code is extracted and placed in separate secure blocks that are isolated from the accessible blocks. During initialization, the system can temporarily map addresses to secure blocks for boot code execution. After initialization, the mapping is removed or remapped, taking out the secure blocks from the accessible address space. This extraction enables flexible code execution during boot while preventing malicious code execution during normal operations.
Solution Approach 2:
The system performs preliminary validation of boot code integrity before allowing any address mapping to secure blocks. Configuration settings are validated during initialization before the memory map is configured to access secure blocks. This preliminary action ensures that only validated, non-malicious code can be executed, resolving the security risk while maintaining execution flexibility.
Data Source
AI summary
Provided are a method, device, and system for booting from a memory device having an array of blocks of cells. An initial memory map has a mapping of memory addresses to accessible blocks of cells in the memory device that are accessible following a boot sequence. There are secure blocks of cells in addition to the accessible blocks of cells that are not accessible through the memory addresses in the initial memory map. In response to detecting an initialization event, the secure blocks of cells are mapped to a range of memory addresses in the memory map to generate an altered memory map. Code is executed in the secure blocks using the range of memory addresses in the altered memory map. The range of memory addresses mapping to the secure blocks are remapped to map to the accessible blocks to which the range of memory addresses mapped in the initial memory map to restore the initial memory map from the altered memory map.