Consider creating a wrapper for hyperlight-host that locates sandboxes in remote processes

It should be possible to create a drop-in replacement for the hyperlight-host crate that exposes the same public API, but wraps the UninitializedSandbox and MultiUseSandbox types with wrappers that implement its calls via (optionally?) making RPCs to different processes. This might be useful for people who wish to run sandboxes in remote, low-privilege processes for even-more-defense-in-depth (e.g. against hypervisor kernel vulnerabilities), and might allow working around per-process resource limits.

This should be possible to do via a new crate which is a drop-in wrapper around the hyperlight-host crate, avoiding the need for any changes in Hyperlight itself.

Semantically, it also shouldn't require any changes to other crates that depend on hyperlight-host, like hyperlight-{wasm,js,unikraft}. Unfortunately, due to rust-lang/cargo#9227, there may be distribution challenges due to the inability to for a root crate to override hyperlight-host with some hypothetical hyperlight-host-remote-process-wrapper throughout the transitive dependency graph. The wrapper crate would either need to use name = "hyperlight-host" and be used as a git/path dependency, or hyperlight-{wasm,js,unikraft} would need to be made aware of its existence/configured to optionally depend on it.

@simongdavies

I believe @simongdavies had a proposal for something like this based on the OpenVMM mesh framework, but I don't think we ever pursued that.

Any specific reason you think this should be in a separate crate with compatible api, instead of being some kind of config?

I believe @simongdavies had a proposal for something like this based on the OpenVMM mesh framework, but I don't think we ever pursued that.

Yes I built a prototype , it worked very well, it provided these options:

The code for hosting the sandbox and host functions in a separate process looked like this:

use std::sync::{Arc, Mutex};

use hyperlight_host::func::host_functions::HostFunction2;
use hyperlight_mesh::{mesh_host_function_registry, sandbox_mesh};
fn main() {
    let mut mesh_host_function_registry =
        mesh_host_function_registry::MeshHostFunctionRegistry::new();

    // Create and register a host function
    let host_function = Arc::new(Mutex::new(|a: i32, b: i32| Ok(a + b)));
    host_function
        .register(&mut mesh_host_function_registry, "Add")
        .unwrap();

    // Run the mesh host
    sandbox_mesh::run_host().expect("Failed to run mesh host");
}

From the work I did on this I think it would be possible to use mesh to provide this capability as a core part of hyperlight, however there are a few things that would need to be done with mesh first:

mesh would need to be extracted from OpenVMM as a standalone crate(s) - I discussed this with them and at that time they were open to this taking place
AFAIK mesh is not implemented on macOS so there would be some additional work there
there were some missing/unfinished capabilities in mesh to allow the spawned process to be locked down , I believe the intent was to incorporate minijails to do this.

Navigation Menu

Repository navigation

Consider creating a wrapper for hyperlight-host that locates sandboxes in remote processes #1706

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Consider creating a wrapper for hyperlight-host that locates sandboxes in remote processes #1706

Description

Activity

syntactically commented on Aug 5, 2026

ludfjig commented on Aug 17, 2026

simongdavies commented on Sep 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions