Hyperprocess Compatibility Layer Without Two-Level Scheduling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing virtualization techniques incur significant overhead and security concerns when executing software created for a first operating system on a second operating system, particularly due to two-level scheduling and resource management inefficiencies.
Innovation Solution
A hyperprocess compatibility layer is introduced between the real kernel and user space, allowing unmodified guest operating system software to run on a host operating system by segregating user mode into restricted and unrestricted modes, with a shared user space and direct emulated kernel access, leveraging the host operating system's task schedule for efficient memory and resource management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If conventional virtualization techniques are used to execute guest operating system software on a host operating system, then software compatibility is achieved, but significant overhead is incurred due to two-level scheduling and resource management inefficiencies
Solution Approach 1:
The patent extracts the compatibility layer functionality from the traditional virtual machine monitor and integrates it directly into the host operating system's user space. By taking out the scheduling overhead from the kernel level and moving it to user space, the system eliminates the need for complex two-level scheduling while maintaining software compatibility.
Solution Approach 2:
The patent introduces an intermediary layer in the form of a user-space compatibility layer that mediates between the host operating system and guest software. This intermediary handles the translation and emulation functions previously requiring kernel-level intervention, thereby reducing scheduling overhead while maintaining compatibility.
2Adaptability or versatility
If conventional virtualization techniques are used to execute guest operating system software on a host operating system, then software compatibility is achieved, but security concerns arise when executing software from one operating system on a different operating system
Solution Approach 1:
The patent segments the execution environment into distinct user-space and kernel-space regions. The compatibility layer operates in user space with controlled access to kernel resources through system calls. This segmentation isolates guest software from direct kernel access, enhancing security while maintaining compatibility.
Solution Approach 2:
The user-space compatibility layer acts as an intermediary that provides a secure interface between guest software and host kernel. It mediates all resource access requests through controlled system calls, preventing direct kernel access and thereby addressing security concerns while maintaining software compatibility.
3Stability of the object's composition
If a two-level scheduler is used with virtual machines, then process isolation is achieved, but system processing and memory resources are consumed and tied up
Solution Approach 1:
The patent extracts the scheduling function from the kernel level and relocates it to user space. By taking out the scheduling overhead, the system eliminates the need for separate virtual machine schedulers and can leverage the host's native scheduler, thereby improving resource utilization while maintaining process isolation through user-space process management.
Solution Approach 2:
The patent merges the virtualization overhead functions into the host operating system's user-space process management mechanisms. By combining the compatibility layer with the host scheduler, the system eliminates redundant scheduling structures and memory allocations, improving productivity while preserving process isolation through user-space process boundaries.
Data Source
AI summary
The technology provides efficient and secure virtualized execution of software compiled for a first (guest) operating system to run on a second (host) operating system. This includes delineating a kernel space and a separate user space, the kernel space including a handle table and kernel of a host operating system. In the user space, a restricted space is separate from an unrestricted space. The restricted space corresponds to a restricted mode and the unrestricted space corresponding to an unrestricted mode. A hyperprocess is implemented and a hyperprocess handle table is created in the unrestricted space. A set of child processes is loaded into separate memory address spaces in the restricted space, wherein the set of child processes is associated with a guest operating system. The hyperprocess handle table is shared among the child processes and includes a file descriptor tables each associated with a specific child process.