Version Tagged Memory Corruption Detection via Spare Bank
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current memory corruption detection methods, such as debugging tools like Oracle Solaris Studio, Purify, Valgrind, and Insure++, significantly slow down program execution due to instrumentation, and are not effective in detecting all memory corruption issues, particularly in type-unsafe languages like C and C++.
Innovation Solution
The system associates version numbers with data structures in physical memory, using a spare bank for memory corruption detection, where adjacent allocated data structures have different version numbers, and the operating system determines reserved and available sets of version numbers to efficiently detect memory corruption without software tools, utilizing error-correcting code (ECC) DRAM and spare-bank memory mechanisms.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If debugging tools like Oracle Solaris Studio, Purify, Valgrind, and Insure++ are used for memory corruption detection, then memory corruption can be detected, but program execution speed decreases significantly (hundreds of times slower)
Solution Approach 1:
The invention divides the memory detection function into hardware-level components (version number tags in metadata, separate version number storage) rather than software instrumentation. This segmentation allows detection to occur at the memory access level without requiring software debugger intervention, thus maintaining execution speed while providing corruption detection.
Solution Approach 2:
The invention replaces the mechanical/software-based debugging approach with a hardware-based mechanism. Version numbers are stored in hardware metadata structures and checked automatically by the memory management unit, eliminating the need for software instrumentation and achieving both detection reliability and execution speed.
2Reliability
If version numbers are associated with all data structures for memory corruption detection, then detection coverage is improved, but memory overhead increases
Solution Approach 1:
The invention applies version number tagging selectively to specific data structures that require corruption detection, rather than uniformly to all memory. The metadata structure contains version numbers only for allocated data structures, and the system can choose which structures to monitor based on their importance and corruption risk.
Solution Approach 2:
The invention stores version numbers in a separate metadata structure (a copy of version information) rather than embedding them directly in the data structures. This copying approach allows efficient version number management and comparison without duplicating the actual data, minimizing memory overhead while maintaining detection coverage.
3Reliability
If reserved sets of version numbers are determined for each memory region to handle incorrect address indexing, then security against malicious attacks is improved, but system complexity increases
Solution Approach 1:
The invention pre-determines reserved sets of version numbers for each memory region during system initialization or memory allocation, before actual memory access occurs. This preliminary action allows the system to have detection rules ready in place, simplifying the runtime complexity while maintaining security against incorrect address indexing and malicious attacks.
Solution Approach 2:
The invention introduces version numbers as an intermediary mechanism between the memory address and the data structure. This intermediary layer provides a simple comparison operation that mediates the security check, avoiding complex validation logic while effectively preventing unauthorized or incorrect memory access.
Data Source
AI summary
Systems and methods for maximizing a number of available states for a version number used for memory corruption detection. A physical memory may be a DRAM comprising a plurality of regions. Version numbers associated with data structures allocated in the physical memory may be generated so that version numbers of adjacent data structures in a virtual address space are different. A reserved set and an available set of version numbers are associated with each one of the plurality of regions. A version number in a reserved set of a given region may be in an available set of another region. The processor detects no memory corruption error in response to at least determining a version number stored in a memory location in a first region identified by a memory access operation is also in a reserved set associated with the first region.