A lightweight virtualization isolation method and system based on a Rust token mechanism

Abstract

The application discloses a lightweight virtualization isolation method and system based on a Rust token mechanism, and the system comprises a token management module and a trap management module, and the method comprises the following steps: obtaining a resource requirement configuration file, using the token management module to cast corresponding tokens to obtain a token structure body, and transferring the ownership of the tokens to a VM object; consuming Cpu tokens and completing the initialization of CPU context, so that a Guest OS starts to execute; when a synchronous exception trap is triggered, the trap management module obtains corresponding exception tokens and matches strategies to process; when a super call HVC trap is triggered and management operation is performed, the trap management module obtains corresponding HVC tokens and management tokens and performs verification, and after the verification is passed, corresponding management instructions are executed. The tokenization resource isolation method can guarantee high security, reduce runtime overhead, and has good verifiability, portability and expansibility.

Description

Technical Field

[0001] This invention relates to virtualization technology, specifically to a lightweight virtualization isolation method and system based on the Rust token mechanism. Background Technology

[0002] Edge computing and embedded systems (such as automotive electronics, industrial control, and aerospace) are evolving from distributed deployments of "multi-chip, multi-board" to converged architectures of "single-board, multi-domain, and secure isolation." To simultaneously meet the needs of mixed-criticality business operations, real-time and deterministic requirements, as well as security and compliance, the industry requires a low-overhead, easily auditable, and formally verifiable virtualization isolation solution.

[0003] Rust's ownership and borrowing checks, zero-cost abstractions, and availability in no_std environments allow it to move "permissions / isolation" to compile-time constraints, minimizing runtime checks and state. By minimizing unsafe boundaries, it can significantly minimize the Trusted Computing Base (TCB) and auditing costs, meeting the needs of security-critical and embedded virtualization.

[0004] Most existing solutions rely on runtime resource tables, policy engines, access control, or trap paths for permission determination. Unauthorized access is often denied only at runtime, lacking a strong guarantee of "unreachable at compile time," which leads to complex state machines, increased TCBs, and unclear audit boundaries. Summary of the Invention

[0005] The technical problem to be solved by this invention is to provide a lightweight virtualization isolation method and system based on the Rust token mechanism, which reduces runtime overhead while ensuring high security through tokenized resource isolation, and has good verifiability, portability and scalability.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0007] A lightweight virtualization isolation method based on the Rust token mechanism, the method being applied to a lightweight virtualization isolation system including a token management module and a trap management module, the method comprising the following steps:

[0008] After completing the early initialization in EL3, the system enters the EL2 environment. The type-1 hypervisor of EL2 obtains the resource requirement configuration files of each GuestOS and uses the built-in public key to sign and verify the configuration files. The information in the resource requirement configuration files includes, but is not limited to, CPU quantity information, memory range information, MMIO device information, interrupt number information, and shared memory channel information.

[0009] The token management module uses the resource requirements of each Guest OS to mint a set of non-replicable tokens that only support ownership transfer for each Guest OS. The minted tokens are aggregated into a token structure VmTokens. The corresponding VM object of the Guest OS is constructed using the token structure VmTokens, and the ownership of the tokens is transferred to the VM object.

[0010] Call the specified interface to consume the CPU token in the VmTokens structure and complete the initialization of the CPU context. Jump from the EL2 environment to the EL1 or EL0 environment through the eret instruction to start the Guest OS.

[0011] When the Guest OS triggers a synchronization exception trap, the trap management module obtains the exception token ExceptionToken from the corresponding token structure VmTokens and processes it according to the corresponding strategy. When the Guest OS triggers a Hyper Call (HVC) trap, the trap management module obtains the HVC token HvcToken from the corresponding token structure VmTokens and verifies it. If it is a management operation, the trap management module also obtains the management token ManagementToken from the corresponding token structure VmTokens and verifies it. After both the HVC token HvcToken and the management token ManagementToken are verified, the corresponding management instruction is executed.

[0012] Furthermore, when the token management module mints a set of non-copyable tokens that only support ownership transfer for each Guest OS according to the resource requirements of each Guest OS, all tokens do not implement Copy or Clone to ensure non-copyability. The PhantomData<*mut()> is used to automatically infer the type as !Send / !Sync to prevent cross-core sharing, and the pub(crate) constructor and private fields ensure that the tokens can only be constructed within EL2.

[0013] Furthermore, the token management module, based on the resource requirements of each Guest OS, mints a set of non-replicable tokens that only support ownership transfer for each Guest OS. When aggregating the various minted tokens into a token structure VmTokens, the following steps are included:

[0014] The system retrieves various information from the resource requirement configuration file, such as CPU quantity, memory range, MMIO device information, interrupt number information, and shared memory channel information, and converts them into a parameter view of a Params structure. Then, it constructs corresponding token slices from the parameter slices in the parameter view using the `unsafe { core::mem::transmute}` command, so that the token directly carries a read-only reference to the corresponding parameter. Finally, the token slices are assembled into tokens for different Guest OSs. If the management flag in the resource requirement configuration file of the Guest OS is a specified value, a corresponding management token, `ManagementToken`, is also minted for this VM.

[0015] Aggregate all tokens in the current Guest OS into a token structure VmTokens, and set the token generation epoch value to the initial value.

[0016] Furthermore, after aggregating all tokens from the same Guest OS into a token structure VmTokens and setting the token generation epoch to an initial value, the method also includes: calling the finalize method to mark the self.sealed flag of the token management module as a sealed state value to prevent the minting of new tokens.

[0017] Furthermore, when executing the corresponding management instructions, it includes:

[0018] If the management instruction is a create instruction, then check if the corresponding VM object exists. If it does not exist, proceed to the next step. If it exists, first stop the corresponding VM object, then destroy the corresponding VM object and discard the corresponding token structure VmTokens, and then proceed to the next step.

[0019] The token management module is invoked to recast a set of non-copyable tokens that only support ownership transfer for the Guest OS according to the resource requirements of the corresponding Guest OS created by the creation instruction. The various tokens are aggregated into a token structure VmTokens. The VM object of the Guest OS is constructed using the token structure VmTokens, and the ownership of the tokens is transferred to the VM object. The value of the token generation epoch is incremented.

[0020] Furthermore, when executing the corresponding management instructions, it includes:

[0021] If the management instruction is the start instruction, then the system locates the created VM object or the stopped VM object, then calls the specified interface to consume the CPU token in the VM object's token structure VmTokens and completes the initialization of the CPU context. It then jumps from the EL2 environment to the EL1 or EL0 environment via the eret instruction, allowing the Guest OS corresponding to the VM object to start execution.

[0022] Furthermore, when executing the corresponding management instructions, it includes:

[0023] If the management command is a stop command, then all CPUs within the virtual domain of the VM object corresponding to the stop command will be suspended.

[0024] Furthermore, when executing the corresponding management instructions, it includes:

[0025] If the management command is a destroy command, then the token structure VmTokens of the VM object corresponding to the destroy command is discarded, the corresponding static parameter slot is reclaimed, and the corresponding VM index is removed.

[0026] Furthermore, if the management instruction is a destroy instruction issued by the management VM itself, the execution of the corresponding management instruction also includes: after the last management VM in the system destroys itself, the CPU of the corresponding domain is put into a suspended state until power-off, wherein the management VM is a VM object containing a management token ManagementToken in the token structure VmTokens.

[0027] The present invention also proposes a lightweight virtualization isolation system based on the Rust token mechanism, including a processor and a computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and the computer program is executed by the processor to implement the steps of the lightweight virtualization isolation method based on the Rust token mechanism.

[0028] Compared with the prior art, the advantages of the present invention are as follows:

[0029] This invention utilizes the inherent characteristics of Rust type systems to solidify permissions into compile-time constraints by forging a set of non-replicable tokens for each Guest OS that only support ownership transfer. Illegal access is denied during the compilation phase, eliminating the overhead of runtime policy table lookups. At the same time, the ownership of the tokens is transferred to the VM object, ensuring that EL2 no longer holds resources during runtime and minimizing the trusted computing base.

[0030] This invention is based on a token mechanism that is non-replicable and only supports ownership transfer. The state machine is simplified to a one-time minting-consumption process. Combined with the aggregated encapsulation of the token structure VmTokens, it facilitates formal verification and auditing.

[0031] This invention relies solely on the Rust language mechanism to execute the standard ARM virtualization process, without being bound to specific hardware; various tokens are aggregated through a unified structure, supporting flexible expansion of new resource types.

[0032] This invention obtains the exception token ExceptionToken from the corresponding token structure VmTokens by trapping the management module and processes it according to the corresponding strategy. After both the HVC token HvcToken and the management token ManagementToken are verified, the corresponding management instructions are executed. This moves access control forward to the type checking stage, replacing runtime checks with compile-time guarantees, and achieves true Type-1 virtualization isolation. Attached Figure Description

[0033] Figure 1 This is a system architecture design diagram of an embodiment of the present invention.

[0034] Figure 2 This describes the token distribution and application process in an embodiment of the present invention.

[0035] Figure 3 This is a virtual machine state transition diagram in an embodiment of the present invention.

[0036] Figure 4 This is a timing diagram of token minting and distribution in an embodiment of the present invention.

[0037] Figure 5 This is a flowchart of the method in an embodiment of the present invention. Detailed Implementation

[0038] The present invention will be further described below with reference to the accompanying drawings and specific preferred embodiments, but this does not limit the scope of protection of the present invention.

[0039] This embodiment proposes a lightweight virtualization isolation method based on the Rust token mechanism. It aims to solve the problem of "permission = token (capability)" being solidified as a compile-time constraint by leveraging the Rust language's type system and ownership model, without relying on runtime resource tables and schedulers.

[0040] 1. Provides strong isolation and determinism in Type-1 virtualization scenarios.

[0041] 2. Access to resources such as CPU / memory / interrupts / MMIO / shared memory / synchronization exceptions is moved to the type checking stage for authorization or denial.

[0042] 3. Minimize the unsafe boundary and TCB to reduce audit and certification costs.

[0043] 4. Compared to runtime isolation schemes, it significantly reduces path and trap overhead, achieving near-bare-metal performance.

[0044] The core idea of ​​this embodiment is "token as capability". CpuToken is generated and issued once during the boot phase, and resources such as pCPU, page table, MMIO, IRQ, etc. are bound to the corresponding Guest OS with non-replicable type tokens. No scheduling / management is performed at runtime, and true Type-1 virtualization is achieved through language-level isolation.

[0045] Meanwhile, by changing the manage_bit in the Guest configuration file, any number of GuestOS can be upgraded to management VMs, flexibly realizing the management capabilities of a hypervisor.

[0046] The method of this embodiment is described using ARMv8-A as an example. However, it should be noted that the method of this embodiment is not limited to the ARM architecture. Other architectures can also use equivalent privileged interfaces and tokenization mechanisms to achieve the same technical effect.

[0047] The method in this embodiment is applied to Figure 1 The system shown is a lightweight virtualization isolation system including a token management module and a trap management module. This solution mainly focuses on the token management module and the trap management module, which are the core components of this solution. Other basic virtualization components (such as memory management, interrupt control, memory sharing, device drivers, etc.) are implemented by combining with the core components through reserved APIs and are not within the scope of this solution.

[0048] In this embodiment, the goal of the Token Manager module is to complete the token "minting and distribution" in one go during the EL2 bootstrap phase, generating a total token package VmTokens for each guest; no permissions are added or modified during runtime (except for Trap Manager calls). The token distribution and application process can be found in the appendix. Figure 2 The relevant content is as follows:

[0049] Input: Guest Config - Contains basic information and policy items for each Guest OS, such as: guest.id (identifier), guest.cpus (pCPU set bitmap), guest.manage_bit (whether it is a management VM), guest.policy.hvc_mask (allowed hypercall set), guest.policy.exception (synchronization exception category whitelist), guest.mmio, guest.shm, and other resource parameters (used for API integration with external components).

[0050] Output: VmTokens: Contains the overall structure of all token types for this Guest OS (such as the list of CpuTokenSet, HvcToken, ExceptionToken, optional ManagementToken, etc.) and all information in the Guest Config.

[0051] Constraints and invariants: Token construction is only visible within EL2; tokens cannot be copied (Clone / Copy is not implemented), only ownership can be transferred and controlled borrowing is allowed; after finalization, the Token Manager no longer has the ability to mint tokens (to prevent tampering).

[0052] Note: Other virtualization components (memory management, interrupt control, device drivers, etc.) are combined with the token management module via API.

[0053] In this embodiment, the Trap Manager aims to minimize EL2 intervention, handling only two types of traps: synchronization exceptions (handled according to the ExceptionToken whitelist and policy) and Hyper Calling (HVC) (handled according to the HvcToken authorization set and ManagementToken management capabilities). Management commands (create, start, stop, destroy) are issued via HVC. Both ManagementToken and HvcToken must be held simultaneously to execute management commands. A general policy table is not maintained at runtime; unauthorized paths are unreachable during compilation / linking. Related content is as follows:

[0054] Input and Behavior:

[0055] (1) Synchronize the abnormal entry point and classify and handle it according to the ExceptionToken strategy (such as recording, isolating, or sending to the object).

[0056] (2) HVC entry point, verify HvcToken; if it is a management operation, ManagementToken is also required. For details on virtual machine state migration, please refer to the appendix. Figure 3 :

[0057] create: Nonexistent / Destroyed → Created (forging or recasting tokens)

[0058] start: Created / Stopped → Started (Consumes the start right of CpuTokenSet)

[0059] stop: Started → Stopped (Suspends CPU usage within the virtual domain)

[0060] destroy: Started / Stopped / Created → Destroyed (drop token)

[0061] Output: Processing results conforming to the policy (error codes / event logs / minimum context adjustments); maintaining security boundaries that do not change the state of unauthorized resources.

[0062] Self-behavior of managed VMs: Managed VMs can self-destruct or create / destroy other managed VMs; when the last managed VM in the system self-destructs, it is considered to have no management function, and the CPU of the corresponding domain enters a suspended state until power-off. If no managed VM is configured in the config file, it is considered a hypervisor without management function.

[0063] Note: Access details for interrupt paths (IRQ), stage two page tables, and MMIO / shared memory are handled by external virtualization components; this module only provides tokenization entry points and policy execution for HVC / synchronization exceptions.

[0064] Based on the aforementioned system, such as Figure 5 As shown, the method in this embodiment includes the following steps:

[0065] S101: The introductory phase, specifically involving token minting and distribution. See the attached timeline for a detailed timeline diagram. Figure 4 This includes the following steps:

[0066] (1) After the system completes the early initialization from EL3, it enters the EL2 environment: EL2, as a type-1 hypervisor, takes over the initial control of all hardware resources.

[0067] (2) The EL2 type-1 hypervisor obtains the resource requirement configuration file Guestconfig for each Guest OS and parses the Guest config file: it uses the built-in public key to sign and verify the configuration file to ensure that the config has not been tampered with. The config file describes the resource requirements of each Guest. The resource requirement configuration file can freely configure system resources according to the virtualization scheme. Its information includes CPU quantity information, memory range information, MMIO device information, interrupt number information, and shared memory channel information, etc. The code example is as follows:

[0068] pub struct GuestSpec<'a>{

[0069] pub id: GuestId,

[0070] pub cpu_mask: u128, / / Bound pCPU bitmap

[0071] pub mem:&'a [MemDesc], / / List of memory segments

[0072] pub mmio:&'a [MmioDesc], / / List of MMIO segments for the device

[0073] pub irqs:&'a [u32], / / List of interrupt numbers

[0074] pub shm:&'a [ShmDesc], / / List of shared memory segments

[0075] pub manage_bit: bool, / / Whether to manage VMs

[0076] pub exception_classes:&'a [u16], / / Whitelist of synchronization exception classes

[0077] pub hvc_mask: u64, / / Set of allowed hypercall authorizations

[0078] (3) Initialize the token management module: EL2 starts the token management module Token Manager as the global resource allocation center. Token Manager maintains a one-time resource pool to ensure that each hardware resource cannot be allocated repeatedly after allocation.

[0079] (4) Token Minting: The token management module generates corresponding token objects for each type of resource based on the resource allocation strategy parsed in the config. Each token is minted once, has unique ownership, cannot be cloned or copied, and can only be moved or borrowed. Specifically, the token management module mints a set of non-copyable tokens that only support ownership transfer for each Guest OS based on the resource requirements of each Guest OS, resulting in the following tokens:

[0080] CpuTokenSet: Binds pCPU resources;

[0081] MemToken slice: Binds to memory page table resources;

[0082] MmioToken slice: Binds MMIO device resources;

[0083] IrqToken slice: Bind to IRQ interrupt resources;

[0084] ShmToken slices: bind to shared memory resources;

[0085] ExceptionToken slice: Binds to the synchronous exception handling strategy;

[0086] HvcToken: Binds to the collection of supercall authorizations;

[0087] ManagementToken (optional): Minted when manage_bit is true, identifying management VM privileges.

[0088] The process is as follows:

[0089] The system retrieves information from the resource requirement configuration file, including CPU count, memory range, MMIO device information, interrupt number, and shared memory channel information. This information is then converted into a parameter view of a Params structure. The parameter slices in this view are then constructed into corresponding token slices using the `unsafe { core::mem::transmute}` command. Each token slice carries a read-only reference to its corresponding parameter. Finally, these token slices are assembled into tokens for different Guest OSs. If the management flag `manage_bit` in the Guest OS's resource requirement configuration file is set to `true`, a corresponding management token `ManagementToken` is also minted for this VM. An example code is shown below.

[0090] / / Convert GuestSpec to parameter view

[0091] let cpu_p = CpuParams { cpu_mask: g.cpu_mask};

[0092] let hvc_p = HvcParams { mask: g.hvc_mask};

[0093] let cpu_ref:&'a CpuParams = unsafe { core::mem::transmute(&cpu_p)};

[0094] let hvc_ref:&'a HvcParams = unsafe { core::mem::transmute(&hvc_p)};

[0095] / / Map the desc list to parameter views and Token lists

[0096] let mem_params:&'a [MemParams]= unsafe { core::mem::transmute(g.mem)};

[0097] let mmio_params:&'a [MmioParams]= unsafe { core::mem::transmute(g.mmio)};

[0098] let irq_params:&'a [IrqParams]= unsafe {

[0099] / / Wrap the u32 IRQ list into IrqParams

[0100] core::slice::from_raw_parts(g.irqs.as_ptr() as *const IrqParams,g.irqs.len())

[0101] };

[0102] let shm_params:&'a [ShmParams]= unsafe { core::mem::transmute(g.shm)};

[0103] let exc_params:&'a [ExceptionParams] = unsafe {

[0104] core::slice::from_raw_parts(g.exception_classes.as_ptr() as *const ExceptionParams, g.exception_classes.len())

[0105] };

[0106] / / Treat the parameter slice as a Token slice (it is recommended to explicitly construct in the project to avoid transmute)

[0107] let mem_tokens: &'a [MemToken] = unsafe { core::mem::transmute(mem_params)};

[0108] let mmio_tokens: &'a [MmioToken] = unsafe { core::mem::transmute(mmio_params)};

[0109] let irq_tokens: &'a [IrqToken] = unsafe { core::mem::transmute(irq_params)};

[0110] let shm_tokens: &'a [ShmToken] = unsafe { core::mem::transmute(shm_params)};

[0111] let exc_tokens: &'a [ExceptionToken] = unsafe { core::mem::transmute(exc_params)};

[0112] let cpu = CpuTokenSet { p: cpu_ref, _priv: PhantomData};

[0113] let hvc = HvcToken { p: hvc_ref, _priv: PhantomData};

[0114] let mgmt = if g.manage_bit { Some(ManagementToken { _priv: PhantomData})} else { None};

[0115] It should be noted that in this embodiment, when constructing a token slice, converting various information into a parameter view of a Params structure, and then constructing the parameter slice in the parameter view into the corresponding token slice using the unsafe { core::mem::transmute} command is only one way in the code example, not the only way. Other Rust syntax can also be used to achieve the same effect.

[0116] In this embodiment, when minting a set of non-copyable tokens that only support ownership transfer for each Guest OS, all tokens do not implement Copy or Clone to ensure non-copyability. PhantomData<*mut()> is used to automatically infer the type as !Send / !Sync to prevent cross-core sharing. The pub(crate) constructor and private fields ensure that tokens can only be constructed within EL2. A code example is shown below:

[0117] use core::marker::PhantomData;

[0118] pub struct CpuTokenSet<'a>{ pub(crate) p:&'a CpuParams, _priv:PhantomData<*mut ()>}

[0119] pub struct MemToken<'a>{ pub(crate) p:&'a MemParams, _priv:PhantomData<*mut ()>}

[0120] pub struct MmioToken<'a>{ pub(crate) p:&'a MmioParams, _priv:PhantomData<*mut ()>}

[0121] pub struct IrqToken<'a>{ pub(crate) p:&'a IrqParams, _priv:PhantomData<*mut ()>}

[0122] pub struct ShmToken<'a>{ pub(crate) p:&'a ShmParams, _priv:PhantomData<*mut ()>}

[0123] pub struct ExceptionToken<'a>{ pub(crate) p:&'a ExceptionParams, _priv: PhantomData<*mut ()>}

[0124] pub struct HvcToken<'a>{ pub(crate) p:&'a HvcParams, _priv:PhantomData<*mut ()>}

[0125] / / Management token (only the management VM has this)

[0126] pub struct ManagementToken { _priv: PhantomData<*mut ()>}

[0127] (5) Assemble VM objects: Aggregate the various tokens minted into a token structure VmTokens as a token set. Use the token set to construct a VM object, that is, use the token structure VmTokens to construct the VM object corresponding to the Guest OS, and set the token generation epoch value to the initial value 1. Finally, transfer the ownership of the tokens to the VM object. TokenManager itself no longer holds these resources. At the same time, in order to prevent the generation of new permissions at runtime, the minting capability of TokenManager can be turned off. Specifically, the finalize method is called to mark the sealing flag self.sealed of the token management module as true, so as to prevent the minting of new tokens.

[0128] (6) Start Guest VM: Call the specified interface launch_guest(), consume the Cpu token (CpuToken) in the token structure VmTokens and complete the initialization of the CPU (which can be a physical CPU or a virtual CPU, and can be freely selected according to the virtualization scheme) context, jump from the EL2 environment to the EL1 or EL0 environment through the eret instruction, and let GuestOS start execution.

[0129] S102: Runtime Phase: After the Guest OS starts, EL2 only handles two types of traps through the Trap Manager module, and does not maintain a general resource table or scheduler during runtime.

[0130] Synchronization exception handling: When the Guest OS triggers a synchronization exception trap, the trap management module obtains the exception token ExceptionToken from the corresponding token structure VmTokens and matches it with the corresponding strategy for processing.

[0131] Hypercall Handling: When the Guest OS triggers a Hypercall (HVC) trap, the trap management module retrieves and verifies the HVC token (HvcToken) from the corresponding token structure (VmTokens). If it is a management operation (such as create, start, stop, destroy), the trap management module also retrieves and verifies the management token (ManagementToken) from the corresponding token structure (VmTokens). After both the HVC token (HvcToken) and the management token (ManagementToken) are verified, the corresponding management instruction is executed. Executing the corresponding management instruction includes:

[0132] (1) If the management instruction is a create instruction, check if the corresponding VM object exists. If it does not exist, proceed to the next step. If it exists, stop the corresponding VM object first, then destroy the corresponding VM object and discard the corresponding token structure VmTokens, and then proceed to the next step.

[0133] The token management module is invoked to recast a set of non-copyable tokens that only support ownership transfer for the Guest OS according to the resource requirements of the corresponding Guest OS created by the creation instruction. The various tokens are aggregated into a token structure VmTokens. The VM object of the Guest OS is constructed using the token structure VmTokens, and the ownership of the tokens is transferred to the VM object. The value of the token generation epoch is incremented.

[0134] (2) If the management instruction is the start instruction, then find the created VM object or the stopped VM object, then call the specified interface to consume the Cpu token in the token structure VmTokens of the VM object and complete the initialization of the CPU context. Jump from the EL2 environment to the EL1 or EL0 environment through the eret instruction, so that the Guest OS corresponding to the VM object can start execution.

[0135] (3) If the management command is a stop command, then all CPUs in the virtual domain of the VM object corresponding to the stop command are suspended.

[0136] (4) If the management instruction is a destroy instruction, then the token structure VmTokens of the VM object corresponding to the destroy instruction is discarded, the corresponding static parameter slot is reclaimed, and the corresponding VM index is removed. If the management instruction is a destroy instruction issued by the management VM itself, after the last management VM in the system destroys itself, the CPU of the corresponding domain will be put into a suspended state until power-off. In this embodiment, the management VM is a VM object whose token structure VmTokens contains the management token ManagementToken.

[0137] The Rust code example of the method in this embodiment is as follows:

[0138] 1. Guest config parsing results

[0139] / / Parser placeholder (the specific implementation is determined according to the format of the config file)

[0140] / / pub fn parse_config(bytes:&[u8]) ->Result<Config, ErrorCode> { ...}

[0141] #[repr(u8)]

[0142] pub enum MemAttr { Ro, Rw, X, Device}

[0143] pub struct MemDesc { pub pa: usize, pub size: usize, pub attr:MemAttr}

[0144] pub struct MmioDesc { pub base: usize, pub size: usize, pub device_id: u32}

[0145] pub struct ShmDesc{ pub pa: usize, pub size: usize, pub perm: u8} / / 0:R,1:W,2:RW

[0146] pub struct GuestSpec<'a>{

[0147] pub id: GuestId,

[0148] pub cpu_mask: u128, / / Bound pCPU bitmap

[0149] pub mem:&'a [MemDesc], / / List of memory segments

[0150] pub mmio:&'a [MmioDesc], / / List of MMIO segments for the device

[0151] pub irqs:&'a [u32], / / List of interrupt numbers

[0152] pub shm:&'a [ShmDesc], / / List of shared memory segments

[0153] pub manage_bit: bool, / / Whether to manage VMs

[0154] pub exception_classes:&'a [u16], / / Whitelist of synchronization exception classes

[0155] pub hvc_mask: u64, / / Set of allowed hypercall authorizations

[0156] }

[0157] pub struct Config<'a>{

[0158] pub guests:&'a [GuestSpec<'a>],

[0159] }

[0160] 2. Hypervisor Token and Resource Parameter Structure

[0161] / =========== Resource Parameter Structure (Static Parameter View) ===========

[0162] / / The token internally carries read-only references (zero-copy) to these parameters as a combination of "capability + parameter".

[0163] pub struct CpuParams { pub cpu_mask: u128}

[0164] pub struct MemParams { pub pa: usize, pub size: usize, pub attr:MemAttr}

[0165] pub struct MmioParams { pub base: usize, pub size: usize, pub device_id: u32}

[0166] pub struct IrqParams{ pub irq: u32, pub flags: u32} / / flags: trigger / target kernel and other policy bits

[0167] pub struct ShmParams{ pub pa: usize, pub size: usize, pub perm: u8}

[0168] pub struct ExceptionParams { pub class: u16, pub action: u8} / / action: strategy / action

[0169] pub struct HvcParams { pub mask: u64}

[0170] / / ============ Token Type (Token = Capability + Parameter View) ===========

[0171] / / Note: Constructors and private fields are not exported, and Clone / Copy is not implemented to ensure "unforgeable / uncopyable".

[0172] use core::marker::PhantomData;

[0173] pub struct CpuTokenSet<'a>{ pub(crate) p:&'a CpuParams, _priv:PhantomData<*mut ()>}

[0174] pub struct MemToken<'a>{ pub(crate) p:&'a MemParams, _priv:PhantomData<*mut ()>}

[0175] pub struct MmioToken<'a>{ pub(crate) p:&'a MmioParams, _priv:PhantomData<*mut ()>}

[0176] pub struct IrqToken<'a>{ pub(crate) p:&'a IrqParams, _priv:PhantomData<*mut ()>}

[0177] pub struct ShmToken<'a>{ pub(crate) p:&'a ShmParams, _priv:PhantomData<*mut ()>}

[0178] pub struct ExceptionToken<'a>{ pub(crate) p:&'a ExceptionParams, _priv: PhantomData<*mut ()>}

[0179] pub struct HvcToken<'a>{ pub(crate) p:&'a HvcParams, _priv:PhantomData<*mut ()>}

[0180] / / Management token (only the management VM has this)

[0181] pub struct ManagementToken { _priv: PhantomData<*mut ()>}

[0182] / / ============ Guest's "Total Token Pack" ===========

[0183] / / All tokens of a guest are aggregated together, and no more are added or changed at runtime; compatible with no_std / static design.

[0184] pub struct VmTokens<'a>{

[0185] pub cpu: CpuTokenSet<'a>,

[0186] pub mem:&'a [MemToken<'a>],

[0187] pub mmio:&'a [MmioToken<'a>],

[0188] pub irq:&'a [IrqToken<'a>],

[0189] pub shm:&'a [ShmToken<'a>],

[0190] pub exception:&'a [ExceptionToken<'a>],

[0191] pub hvc: HvcToken<'a>,

[0192] pub mgmt: Option <managementtoken> / / This only exists if manage_bit = true

[0193] pub epoch: u32, / / Token generation (increments during creation, used for lightweight path validation)

[0194] }

[0195] 3. The TokenManager interface needs to be combined with other virtualization components (memory management, interrupt control, device drivers, etc.) via API.

[0196] / / ============ TokenManager Interface ===========

[0197] / / For internal use only in EL2; responsible for: generating parameter view → minting tokens → assembling VmTokens → sealing.

[0198] pub struct TokenManager<'m>{

[0199] config:&'m Config<'m>,

[0200] sealed: bool,

[0201] }

[0202] impl<'m>TokenManager<'m>{

[0203] / / Initialize and complete config verification / resource non-overlapping checks, etc.

[0204] pub fn new(config:&'m Config<'m>) ->Result<Self, ErrorCode> {

[0205] / / TODO: Verify / Inspect

[0206] Ok(Self { config, sealed: false})

[0207] }

[0208] / / Assembles a guest's VmTokens (one-time minting), returning a read-only reference slice (zero-copy).

[0209] pub fn assemble_for_guest<'a>(&'a self, guest_id: GuestId) ->Result<VmTokens<'a>, ErrorCode>{

[0210] if self.sealed { return Err(ErrorCode::NotAuthorized);}

[0211] let g = self.config.guests.iter().find(|x| x.id == guest_id).ok_or(ErrorCode::NotFound)?;

[0212] / / Convert GuestSpec to parameter view

[0213] let cpu_p = CpuParams { cpu_mask: g.cpu_mask};

[0214] let hvc_p = HvcParams { mask: g.hvc_mask};

[0215] let cpu_ref:&'a CpuParams = unsafe { core::mem::transmute(&cpu_p)};

[0216] let hvc_ref:&'a HvcParams = unsafe { core::mem::transmute(&hvc_p)};

[0217] / / Map the desc list to parameter view and Token list

[0218] let mem_params:&'a [MemParams]= unsafe { core::mem::transmute(g.mem)};

[0219] let mmio_params:&'a [MmioParams]= unsafe { core::mem::transmute(g.mmio)};

[0220] let irq_params:&'a [IrqParams]= unsafe {

[0221] / / Wrap the u32 IRQ list into IrqParams

[0222] core::slice::from_raw_parts(g.irqs.as_ptr() as *const IrqParams,g.irqs.len())

[0223] };

[0224] let shm_params:&'a [ShmParams]= unsafe { core::mem::transmute(g.shm)};

[0225] let exc_params:&'a [ExceptionParams] = unsafe {

[0226] core::slice::from_raw_parts(g.exception_classes.as_ptr() as *constExceptionParams, g.exception_classes.len())

[0227] };

[0228] / / Treat parameter slices as token slices (explicit construction in the project is recommended to avoid transmute).

[0229] let mem_tokens:&'a [MemToken]= unsafe { core::mem::transmute(mem_params)};

[0230] let mmio_tokens:&'a [MmioToken]= unsafe { core::mem::transmute(mmio_params)};

[0231] let irq_tokens:&'a [IrqToken]= unsafe { core::mem::transmute(irq_params)};

[0232] let shm_tokens:&'a [ShmToken]= unsafe { core::mem::transmute(shm_params)};

[0233] let exc_tokens:&'a [ExceptionToken]= unsafe { core::mem::transmute(exc_params)};

[0234] let cpu = CpuTokenSet { p: cpu_ref, _priv: PhantomData};

[0235] let hvc = HvcToken { p: hvc_ref, _priv: PhantomData};

[0236] let mgmt = if g.manage_bit { Some(ManagementToken { _priv:PhantomData})} else { None};

[0237] Ok(VmTokens { cpu, mem: mem_tokens, mmio: mmio_tokens, irq: irq_tokens, shm: shm_tokens, exception: exc_tokens, hvc, mgmt, epoch: 1})

[0238] }

[0239] / / Sealing: After the bootstrapping process is complete, new tokens cannot be minted to prevent the generation of new capabilities during runtime.

[0240] pub fn finalize(&mut self) { self.sealed = true;}

[0241] }

[0242] 4. TrapManager interface.

[0243] / / ============ TrapManager Interface ===========

[0244] / / Only handles management-type HVC and synchronization exception policies. Four management operations: create / start / stop / destroy.

[0245] #[repr(u16)]

[0246] pub enum TrapErr {

[0247] NotAuthorized = 1,

[0248] InvalidState,

[0249] NoResources

[0250] AlreadyExists,

[0251] Not Found

[0252] Internal

[0253] }

[0254] pub struct VmSpec<'a>{

[0255] pub id: GuestId,

[0256] pub cpu_mask: u128,

[0257] pub mem:&'a [MemDesc],

[0258] pub mmio:&'a [MmioDesc],

[0259] pub irqs:&'a [u32],

[0260] pub shm:&'a [ShmDesc],

[0261] pub manage_bit: bool,

[0262] pub exception_classes:&'a [u16],

[0263] pub hvc_mask: u64,

[0264] }

[0265] pub struct TrapManager;

[0266] impl TrapManager {

[0267] / / Create / rebuild VM: Remint tokens (if they already exist, stop → drop → remint), register new VmTokens (epoch+1)

[0268] pub fn create(&mut self,

[0269] mgmt:&ManagementToken,

[0270] hvc:&HvcToken<'_>,

[0271] spec:&VmSpec) ->Result<(), TrapErr>{

[0272] / / 1) Validate authorization (mgmt+hvc) 2) Resource check 3) TokenManager reforging 4) Register index

[0273] Ok(())

[0274] }

[0275] / / Start VM: Consumes the start right of CpuTokenSet, sets the context and sets the start right.

[0276] pub fn start(&mut self,

[0277] mgmt:&ManagementToken,

[0278] hvc:&HvcToken<'_>,

[0279] vm_id: GuestId) ->Result<(), TrapErr>{

[0280] Ok(())

[0281] }

[0282] / / Stop VM: Suspend CPUs within the domain, retain token set

[0283] pub fn stop(&mut self,

[0284] mgmt:&ManagementToken,

[0285] hvc:&HvcToken<'_>,

[0286] vm_id: GuestId) ->Result<(), TrapErr>{

[0287] Ok(())

[0288] }

[0289] / / Destroy the VM: drop the token, reclaim the static parameter slot, and remove the index.

[0290] pub fn destroy(&mut self,

[0291] mgmt:&ManagementToken,

[0292] hvc:&HvcToken<'_>,

[0293] vm_id: GuestId) ->Result<(), TrapErr>{

[0294] Ok(())

[0295] }

[0296] / / Synchronize exception handling (by ExceptionToken strategy)

[0297] pub fn handle_sync_exception<'a>(&mut self, tokens:&VmTokens<'a>,syndrome: u32) ->Result<(), TrapErr>{

[0298] Ok(())

[0299] }

[0300] / / Management HVC entry point (mapped to four operations)

[0301] pub fn handle_hvc<'a>(&mut self, tokens:&VmTokens<'a>, call_id: u32,args:&[usize]) ->Result<usize, TrapErr> {

[0302] Ok(0)

[0303] }

[0304] }

[0305] Furthermore, this embodiment also proposes a lightweight virtualization isolation system based on the Rust token mechanism. The system includes a microprocessor and a computer-readable storage medium, in which a computer program is stored. The computer program is executed by the processor to implement the steps of the lightweight virtualization isolation method based on the Rust token mechanism described in this embodiment.

[0306] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0307] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.< / managementtoken>

Claims

1. A lightweight virtualization isolation method based on Rust token mechanism, characterized in that, The method is applied to a lightweight virtualization isolation system including a token management module and a trap management module, and the method includes the following steps: After completing the early initialization in EL3, the system enters the EL2 environment. The type-1 hypervisor of EL2 obtains the resource requirement configuration files of each Guest OS and uses the built-in public key to sign and verify the configuration files. The information in the resource requirement configuration files includes, but is not limited to, CPU quantity information, memory range information, MMIO device information, interrupt number information, and shared memory channel information. The token management module uses the resource requirements of each Guest OS to mint a set of non-replicable tokens that only support ownership transfer for each Guest OS. The minted tokens are aggregated into a token structure VmTokens. The corresponding VM object of the Guest OS is constructed using the token structure VmTokens, and the ownership of the tokens is transferred to the VM object. Call the specified interface to consume the CPU token in the VmTokens structure and complete the initialization of the CPU context. Jump from the EL2 environment to the EL1 or EL0 environment through the eret instruction to start the Guest OS. When the Guest OS triggers a synchronization exception trap, the trap management module obtains the exception token ExceptionToken from the corresponding token structure VmTokens and processes it according to the corresponding strategy. When the Guest OS triggers a Hyper Call (HVC) trap, the trap management module obtains the HVC token HvcToken from the corresponding token structure VmTokens and verifies it. If it is a management operation, the trap management module also obtains the management token ManagementToken from the corresponding token structure VmTokens and verifies it. After both the HVC token HvcToken and the management token ManagementToken are verified, the corresponding management instruction is executed.

2. The lightweight virtualization isolation method based on Rust token mechanism according to claim 1, characterized in that, The token management module, based on the resource requirements of each Guest OS, casts a set of non-copyable tokens that only support ownership transfer for each Guest OS. All tokens do not implement Copy or Clone to ensure non-copyability. PhantomData<*mut()> is used to prevent the type from implementing both Send and Sync features simultaneously, preventing cross-core sharing. The pub(crate) constructor and private fields ensure that the tokens can only be constructed within EL2.

3. The lightweight virtualization isolation method based on Rust token mechanism according to claim 1, characterized in that, The token management module, based on the resource requirements of each Guest OS, mints a set of non-replicable tokens that only support ownership transfer for each Guest OS. When aggregating the various minted tokens into a token structure VmTokens, the following steps are included: The system retrieves each piece of information from the resource requirement configuration file and converts it into a parameter view of a custom resource parameter structure. Then, it constructs the parameter slices in the parameter view into corresponding token slices using the `unsafe { core::mem::transmute}` command, so that the token directly carries a read-only reference to the corresponding parameter. Finally, the token slices are assembled into tokens for different Guest OSs. If the management flag in the resource requirement configuration file of a Guest OS is a specified value, a corresponding management token `ManagementToken` is also minted for this VM. Aggregate all tokens in the current Guest OS into a token structure VmTokens, and set the token generation epoch value to the initial value.

4. The lightweight virtualization isolation method based on the Rust token mechanism according to claim 3, characterized in that, After aggregating all tokens from the same Guest OS into a token structure VmTokens and setting the token generation epoch to an initial value, the method further includes calling the finalize method to mark the self.sealed flag of the token management module as a sealed state value to prevent the minting of new tokens.

5. The lightweight virtualization isolation method based on Rust token mechanism according to claim 3, characterized in that, When executing the corresponding management instructions, the following are included: If the management instruction is a create instruction, then check if the corresponding VM object exists. If it does not exist, proceed to the next step. If it exists, first stop the corresponding VM object, then destroy the corresponding VM object and discard the corresponding token structure VmTokens, and then proceed to the next step. The token management module is invoked to recast a set of non-copyable tokens that only support ownership transfer for the Guest OS according to the resource requirements of the corresponding Guest OS created by the creation instruction. The various tokens are aggregated into a token structure VmTokens. The VM object of the Guest OS is constructed using the token structure VmTokens, and the ownership of the tokens is transferred to the VM object. The value of the token generation epoch is incremented.

6. The lightweight virtualization isolation method based on Rust token mechanism according to claim 5, characterized in that, When executing the corresponding management instructions, the following are included: If the management instruction is the start instruction, then the system locates the created VM object or the stopped VM object, then calls the specified interface to consume the CPU token in the VM object's token structure VmTokens and completes the initialization of the CPU context. It then jumps from the EL2 environment to the EL1 or EL0 environment via the eret instruction, allowing the Guest OS corresponding to the VM object to start execution.

7. The lightweight virtualization isolation method based on Rust token mechanism according to claim 6, characterized in that, When executing the corresponding management instructions, the following are included: If the management command is a stop command, then all CPUs within the virtual domain of the VM object corresponding to the stop command will be suspended.

8. The lightweight virtualization isolation method based on Rust token mechanism according to claim 6, characterized in that, When executing the corresponding management instructions, the following are included: If the management command is a destroy command, then the token structure VmTokens of the VM object corresponding to the destroy command is discarded, the corresponding static parameter slot is reclaimed, and the corresponding VM index is removed.

9. The lightweight virtualization isolation method based on the Rust token mechanism according to claim 8, characterized in that, If the management instruction is a destroy instruction issued by the management VM itself, when executing the corresponding management instruction, it also includes: after the last management VM in the system destroys itself, putting the CPU of the corresponding domain into a suspended state until power-off, wherein the management VM is a VM object containing a management token ManagementToken in the token structure VmTokens.

10. A lightweight virtualization isolation system based on the Rust token mechanism, characterized in that, The device includes a processor and a computer-readable storage medium storing a computer program, which is executed by the processor to implement the steps of the lightweight virtualization isolation method based on the Rust token mechanism as described in any one of claims 1 to 9.

Images