Hypervisor Bytecode Interpreter for Safety-Constrained Resource Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The challenge is to enhance safety and maintain high functionality in virtual machine implementations within the Linux operating system kernel, particularly for safety-critical hypervisors, where the need for performance contradicts the requirement of minimizing code and functionality. Existing solutions require native code for device-specific emulation, which compromises safety.
Innovation Solution
A method involving a virtualization system with an interpreter for bytecode or script execution, which assigns processor time and memory space to guest systems, intercepts and processes access requests, and executes specific bytecode or script instructions to access resources, ensuring safety by limiting the instruction set and privilege levels.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If functionality is moved into the hypervisor for performance reasons, then performance is improved, but the amount of code and functionality increases which compromises safety
Solution Approach 1:
The system segments functionality by separating the hypervisor core from device-specific emulation code. The hypervisor contains only essential virtualization functions, while device-specific functionality is implemented as separate bytecode programs that are interpreted, allowing performance-critical functions to be in the hypervisor without increasing its trusted code base size.
Solution Approach 2:
An intermediary bytecode interpretation layer is introduced between the hypervisor and device-specific functionality. This intermediary allows the hypervisor to execute device-specific emulation code without directly containing it, thus maintaining performance while limiting the hypervisor's trusted code base to only the interpreter and essential virtualization logic.
2Productivity
If device-specific emulation functionality is implemented in native code, then performance is improved, but the trusted code base increases compromising safety
Solution Approach 1:
Device-specific emulation functionality is implemented as disposable bytecode programs rather than permanent native code in the hypervisor. These bytecode programs can be loaded, executed, and discarded as needed, allowing device-specific functionality to be available without permanently increasing the hypervisor's trusted code base.
Solution Approach 2:
Native code execution is replaced with bytecode interpretation for device-specific functionality. This substitution allows the system to maintain the performance benefits of having device-specific emulation available while replacing the mechanical inclusion of native code with a lighter-weight interpretation mechanism that doesn't permanently expand the trusted code base.
3Reliability
If the instruction set is limited for safety, then safety is improved, but functionality and adaptability are reduced
Solution Approach 1:
The system implements a dynamic approach where the instruction set executed by the hypervisor changes based on what is needed. The hypervisor contains a limited safe instruction set for core operations, while device-specific functionality is provided through externally supplied bytecode programs that can be loaded as needed, allowing the system to adapt to different device requirements without permanently expanding the core instruction set.
Data Source
Figure 1~2
Figure 3
AI summary
According to the invention a method is provided for accessing a resource of a control unit comprising: executing a virtualization system on at least one processor of the control unit, the virtualization system including an interpreter (28) for bytecode and/or a script, the virtualization system assigning processor time and memory space to at least one guest system; executing a first guest system (24) running on the virtualization system; emitting, by the first guest system (24), an access request (38) to access a resource (5, 7, 32) of the control unit to the virtualization system (22); determining, by the virtualization system (22), that the access request is not allowable for the first guest system (24); loading by the interpreter (28) bytecode instructions and/or script instructions based on the request of the first guest system (24); and executing, by the interpreter (28), the loaded bytecode or script instructions to access the resource (5, 7, 32).