Control-Flow Memory Isolation Using SLAT Violation Remediation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional memory isolation techniques in virtualized systems face overhead issues with full VM isolation and kernel-based container solutions, which can be compromised if the kernel is compromised, and lack fine-grained control over memory access.
Innovation Solution
Implement control-flow based memory access manipulation using second-level paging to isolate code and data, with SLAT violations triggering remediation actions such as logging, protection faults, rebooting, or shutting down the guest, and maintaining separate SLAT views for isolated sections.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If full VM isolation is used to isolate memory, then security and isolation are improved, but system overhead increases
Solution Approach 1:
The patent segments memory into isolated sections with distinct access controls. By dividing memory space into protected regions and applying fine-grained access controls at the section level rather than requiring full VM isolation, the system achieves security with reduced overhead. The host maintains control over specific memory sections while guest OS retains control over other areas.
Solution Approach 2:
The patent applies different access control qualities to different memory regions. Critical kernel subsystems receive strong isolation protections while other memory areas maintain normal access patterns. This localized approach to security allows the system to protect only what is necessary, reducing overall system overhead compared to universal VM isolation.
2Reliability
If kernel-based container solutions are used for memory isolation, then resource isolation is achieved, but security is compromised if the kernel is compromised
Solution Approach 1:
The patent introduces the host as an intermediary layer between the guest OS and physical memory. The host enforces memory access controls and validates control flow before allowing access to isolated sections. This intermediary mechanism provides security without requiring full trust in the guest kernel, as the host can detect and block unauthorized access attempts.
Solution Approach 2:
The patent implements dynamic access control where memory isolation properties change based on control flow state. The host monitors control flow and dynamically adjusts memory access permissions, switching between isolated and non-isolated states based on whether the current execution path is authorized. This dynamic approach provides security adaptability without static kernel-based constraints.
3Device complexity
If conventional container solutions are used, then overhead is reduced compared to full VM isolation, but fine-grained memory access control is lost
Solution Approach 1:
The patent changes the control parameters from coarse-grained container-level isolation to fine-grained section-level control. By controlling memory access at the section level within the guest OS address space, the system achieves detailed control over which memory regions are accessible under what conditions, enabling precise control flow validation without the overhead of full VM isolation.
4Reliability
If second-level paging is used to isolate memory sections, then fine-grained isolation is achieved, but control flow validation becomes complex
Solution Approach 1:
The patent implements feedback mechanisms where the host monitors control flow transitions and validates them against authorized entry and return points. When control flow attempts to enter or exit isolated sections, the host receives feedback about the attempted transition and validates it against the control flow information structure. This feedback loop automates control flow validation, reducing manual complexity while maintaining security.
Data Source
AI summary
Memory address boundaries of an isolated section of code and data is received from a guest in a virtualized system. One or more memory addresses that are legitimate entry points to the isolated section of code is received from the guest. One or more memory addresses that are each a return address of a call made from code in the isolated section into code that is not part of the isolated section is received from the guest. The host receives a second-level address translation (SLAT) violation during execution of a virtual central processing unit (vCPU) of the guest, where the first SLAT violation is associated with a memory address. The host determines that the first SLAT violation resulted from the vCPU attempting to access data in the isolated section of code and data and performs a remediation.