VM and GPU Attestation for Isolation From Untrusted Host OS
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional anti-cheat software installed on operating systems is vulnerable to bypassing due to having a lower privilege level than users, making it easier for cheats to circumvent detection, and frequent updates are required to counter new cheating techniques.
Innovation Solution
Isolate virtual machines (VMs) and GPU state data within a GPU from an untrusted host operating system using a trusted computing base (TCB), which includes a trusted hypervisor to control isolation primitives and prevent access from the host OS, verified through attestation reports.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional anti-cheat software is installed on the operating system, then cheating detection capability is provided, but the software becomes vulnerable to bypassing due to having lower privilege level than users
Solution Approach 1:
The system segments the computing environment into a trusted computing base (TCB) containing the hypervisor and anti-cheat software, and an untrusted host operating system. By isolating the anti-cheat software within the TCB at a higher privilege level, the system prevents bypassing while maintaining detection capability. The hypervisor creates a secure boundary that separates anti-cheat functions from the host OS, ensuring that even if the host OS is compromised, the anti-cheat software remains protected.
Solution Approach 2:
The hypervisor acts as an intermediary between the untrusted host operating system and the trusted anti-cheat software. It mediates all interactions, allowing the anti-cheat software to operate with elevated privileges without direct exposure to the host OS. This intermediary layer enables the anti-cheat system to detect cheating while maintaining security isolation from potentially compromised host environments.
2Reliability
If anti-cheat software is frequently updated to counter new cheating techniques, then detection effectiveness is improved, but system complexity and maintenance burden increase
Solution Approach 1:
The system performs preliminary action by embedding the anti-cheat software within the trusted computing base during the system initialization phase. The hypervisor is configured in advance with security policies and detection mechanisms, establishing a secure environment before cheating attempts can occur. This preliminary setup reduces the need for frequent updates, as the foundational security architecture is already in place to handle new cheating techniques.
Solution Approach 2:
The system implements feedback mechanisms where the hypervisor monitors and reports on cheating detection results to the anti-cheat software. This feedback loop enables the system to adapt to new cheating techniques dynamically, reducing the need for frequent manual updates. The feedback mechanism allows the anti-cheat software to learn from detection patterns and adjust its strategies while maintaining security isolation.
3Reliability
If virtual machines are isolated from the host operating system for security, then cheating prevention is improved, but access to host resources may be restricted
Solution Approach 1:
The system applies local quality by providing different levels of access control to different components within the virtual machine. The hypervisor maintains strict isolation at the system level to prevent cheating, while allowing controlled access to specific host resources (such as GPUs, storage, and network interfaces) through configured policies. This localized approach to quality control ensures security where needed while maintaining operational ease for legitimate resource access.
Solution Approach 2:
The system implements dynamic access control where the hypervisor can adjust resource allocation and access permissions in real-time based on the virtual machine's operational state. The isolation mechanisms are dynamic rather than static, allowing the system to tighten security when cheating attempts are detected while loosening restrictions during normal operation. This dynamic behavior maintains both security isolation and ease of operation across different operational contexts.
Data Source
AI summary
In examples, a VM may receive and aggregate a first attestation report corresponding to a CPU and a second attestation report corresponding to a GPU. The aggregated data may be provided to an attestation service, which may verify the attestation reports indicate a TCB is to include the VM and GPU state data and is to isolate the GPU state data and the VM from an untrusted host OS. Based at least on the TCB being verified, the VM may perform one or more operations using the TCB. The TCB may include a trusted hypervisor to isolate the VM and GPU state data within the GPU(s) from the untrusted host OS. The trusted hypervisor may prevent the host OS from accessing device memory assigned to the VM based at least on controlling an IOMMU and/or second-level address translation (SLAT) used to access the data.