Event Data Structure in Isolated Non-Volatile Memory
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Malware attacks on system code used for startup in computing systems can compromise the integrity of these systems, leading to unauthorized access and operations, and existing protection mechanisms may become compromised, posing risks to system firmware and data.
Innovation Solution
Implementing a secondary non-volatile memory that is electrically isolated from the primary memory to store redundant copies of system firmware and data, along with an embedded controller to monitor and log events securely, ensuring integrity and preventing unauthorized tampering.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a primary non-volatile memory stores system firmware and data, then the system can operate with accessible memory, but the memory may become compromised by malware attacks
Solution Approach 1:
The memory system is divided into two separate non-volatile memory devices: a first non-volatile memory for storing system firmware and an second non-volatile memory for storing event data. This segmentation isolates the firmware from potential malware compromises, as demonstrated when the first memory becomes compromised but the second memory remains intact and can still provide audit trail evidence
Solution Approach 2:
An embedded controller acts as an intermediary between the first non-volatile memory (system firmware) and the second non-volatile memory (event data). The embedded controller independently logs events to the second memory, creating a separate verification path that does not rely on the potentially compromised first memory
2Reliability
If protection mechanisms are implemented to protect system code, then security is improved, but the protection mechanisms themselves may become compromised
Solution Approach 1:
The protection architecture is segmented into independent components: system firmware in the first non-volatile memory, event logging in the second non-volatile memory, and an embedded controller that operates independently. This segmentation ensures that if one protection layer is compromised, others remain functional
Solution Approach 2:
The system creates a separate copy of critical information (event data and audit trails) in the second non-volatile memory that is independent of the first non-volatile memory containing the system firmware. This copying strategy ensures that even if the primary protection mechanism (first memory) is compromised, the copied data in the second memory remains intact for verification
3Reliability
If the embedded controller logs events to non-volatile memory, then event data is preserved securely, but the memory space is consumed
Solution Approach 1:
Memory resources are segmented and allocated to specific functions: the first non-volatile memory is dedicated to system firmware while the second non-volatile memory is dedicated to event data logging. This segmentation ensures that event logging does not consume firmware memory space, and both functions have sufficient dedicated capacity
Solution Approach 2:
The system dynamically manages the event data structure in the second non-volatile memory, adjusting parameters such as event buffer size and logging frequency based on available memory capacity and system needs, allowing flexible optimization between secure logging and memory conservation
Data Source
AI summary
An event data structure is stored in a non-volatile memory that is electrically isolated from a bus accessible by a processor. In response to an event relating to operation of a controller that is separate from the processor, the controller adds event data for the event into an entry of the event data structure.