Exit-Less, Isolated, and Shared Access for Virtual Machines

Virtual machines share memory in one of two bad ways — either map the shared region straight into each guest, which is fast but lets a compromised guest attack its neighbours, or route every access through the host, which is safe but pays a costly trap out of the virtual-machine on each touch; this paper from IIJ Research Laboratory finds a third way, ELISA, which parks the shared data in a separate, trusted page-table view and lets a guest reach it with VMFUNC, an Intel instruction that switches views without trapping, giving isolation at 3.5 times lower overhead than the trap-based approach.

Why this problem is worth solving

The mechanism that makes VMs isolated is also the one that governs sharing, so understanding it explains both the safety and the cost.

The reason mediated sharing is slow comes down to one expensive event that virtualization is built around.

What people did before, and where it broke

• Map the shared region directly into every guest. Put the same host-physical page in each guest’s EPT so they access it natively, with no host involvement. Where it broke. There is no isolation left: a compromised guest can read and corrupt whatever its neighbours put in the shared region, and if the region is a device’s DMA area it can sniff other guests’ I/O.
• Have the host mediate every access via a hypercall. Hide the object in the trusted host and let guests request operations on it. Where it broke. Every access becomes a VM exit at hundreds of nanoseconds, and as devices outpace the CPU this dominates — halving the throughput of an optimized VM networking system.
• Give a guest the device directly, or use SR-IOV hardware. Assign a physical device (or a hardware-virtualized slice of one) straight to a guest. Where it broke. A pass-through device cannot be shared safely across guests for lack of isolation, and SR-IOV puts the switching logic in fixed hardware, so it is not programmable enough for flexible cloud networking.
• Use a lighter isolation primitive like memory protection keys. Intel’s protection keys switch protection domains cheaply, without an exit. Where it broke. Their boundary lives inside a single process’s address space, so they cannot isolate one whole virtual machine from another — the wrong granularity for this problem.
• Build isolation on VMFUNC, as several prior systems did. Earlier work also used VMFUNC’s view-switching to get cheap domain crossings. Where it broke. Each prior system fails one of the two requirements here: many assume the guest kernel is trusted, so they ignore an attack a malicious kernel can mount; the rest keep an untrusted kernel but pay a heavy page-table-maintenance cost — trapping the guest’s page-table register (a 26-times slowdown on a lightweight system call) or forcing a costly register update on every switch.
• The gap. No approach delivered isolation, low overhead, and safety against an untrusted guest kernel at once. Cheap-but-unsafe direct mapping, safe-but-slow host mediation, and prior VMFUNC systems each conceded one of the three. What was missing was a design that used the cheap hardware switch yet held up against a fully untrusted kernel.

How ELISA is put together

The idea

Replace the expensive boundary crossing with a cheap one, and keep the isolation. Host mediation is safe for one reason — the guest cannot touch the shared object without trapping into trusted code — and slow for the same reason, because that trap is a VM exit costing hundreds of nanoseconds. ELISA keeps the safety property while dropping the expensive mechanism. It puts the object in a separate EPT view that the untrusted guest cannot inject code into, so only trusted code ever touches it, exactly as under host mediation; but the guest enters that view with VMFUNC, a hardware instruction that switches the active page table without exiting the virtual machine at all. The crossing falls from 699 nanoseconds to 196, a 3.5-times reduction, and yet the object is still reachable only through code the guest does not control. Getting the protection of a domain boundary while paying only a cheap hardware switch to cross it, rather than a full privileged trap, is the same bargain the fast-isolation-domains work covered elsewhere on this site strikes, walling off sensitive regions with a lightweight processor primitive so that crossing between trust domains stops being the thing that dominates the cost.

Exploit the tree shape of page tables so the guest’s addresses stay valid wherever it moves them. The catch with VMFUNC is that it switches the memory view but not the guest’s page-table pointer, so both the old and new views must have a valid page table at whatever location that pointer names — and an untrusted guest kernel moves that pointer around constantly, for instance on every system call under modern kernel-page-table isolation. Prior systems paid dearly to cope, either trapping every move of the pointer or forcing the guest to fix it up on each switch. ELISA’s Anywhere Page Table sidesteps the whole problem with a structural trick: it fills the entire range of guest-physical addresses the guest could ever use, in the trusted view, with logically duplicated copies of a single page-table root — cheap, because the duplication is done in the EPT mapping, pointing many guest-physical addresses at one real page table. Now wherever the guest plants its page-table root, there is always an identical root at the same address in the trusted view, so the switch just works, with no trap and no fix-up. Reaching for the structure of the page table itself to make address translation fall out for free, rather than paying to police it, is the same move the single-access-page-walk work covered elsewhere on this site makes when it re-lays the translation structures so the hardware finds the answer in one shot instead of grinding through a walk.

Force every entry through one tiny gate that cannot be bypassed. VMFUNC switches the view but not the instruction pointer, so on its own it does not guarantee the guest lands where the trusted code expects — a malicious guest, controlling its own page table, can plant a VMFUNC anywhere and jump into the middle of the trusted code, skipping its permission checks. ELISA closes this with the gate view. While the guest runs normally, its list of switchable views does not even contain the sub view, so it cannot jump there directly; it can only enter the gate, a single 4-kilobyte page of trusted code that is the sole executable page in that view. The gate adds the sub view to the switch list, checks that it really did so — a small self-verification that catches any attempt to skip the setup — then switches in; on the way out the sub code removes itself from the list again, so the next entry must go back through the gate. The whole powerful primitive is thus funneled through one narrow, self-checking chokepoint. Narrowing a dangerous capability down to a single guarded gateway that every use must pass through, and hardening just that one point, is the same strategy the system-call-protection work covered elsewhere on this site adopts, recognizing that if every attack must eventually squeeze through one chokepoint, fortifying that chokepoint protects almost everything behind it.

Following one shared access through ELISA

Interrupts are disabled first because the trusted views have no interrupt handlers; the gate refuses entry if interrupts are still on, a small guard against re-entrancy.

Why it works

• A switch without an exit is far cheaper than a trap. A hypercall forces a full VM exit into the host and back → but VMFUNC changes the active page table entirely within the guest, no exit → so a crossing costs 196 nanoseconds instead of 699, and isolation stops being something you pay hundreds of nanoseconds per access for.
• Keeping the object out of the untrusted view preserves isolation for free. The shared object lives only in a view the guest cannot inject code into → so only ELISA’s trusted code ever touches it, the same guarantee host mediation gives → meaning the cheaper crossing buys no loss of safety, only a loss of cost.
• Duplicating one root everywhere removes the page-table tax that sank prior work. VMFUNC leaves the guest’s page-table pointer unchanged, and the untrusted kernel moves it constantly → but filling the trusted view’s whole address range with copies of one root means a valid root always sits wherever the pointer lands → eliminating the register traps and updates that cost prior untrusted-kernel systems a 26-times slowdown or hundreds of nanoseconds per switch.
• A single self-checking gate closes the bypass attack cheaply. VMFUNC does not force a valid entry point, so a guest could jump into the middle of trusted code → but routing every entry through one 4-kilobyte gate that arms the sub view and verifies it did → makes forging an entry impossible for the price of just one extra switch, about 66 nanoseconds.
• Doing setup in a manager VM makes it usable. The gate and sub views need privileged configuration → but delegating that to a trusted manager VM rather than the host lets ELISA be driven from user space through a small library → so real systems adopt it just by swapping their hypercalls for VMFUNC crossings.

What it costs (trade-offs and scope)

• It is Intel-only. The entire speed advantage rests on VMFUNC, which currently exists only on Intel CPUs; the authors note Intel’s large server share and expect AMD or ARM could add equivalents, but today ELISA does not run elsewhere.
• It is still slower than direct mapping, not faster. Direct sharing remains the fastest option in every benchmark; ELISA’s pitch is isolation at close to direct-mapping speed, and it always carries the per-access switch cost that native sharing does not. The wins are all measured against host mediation, the safe-but-slow baseline.
• The trusted code is load-bearing. Isolation is only as strong as the code installed in the sub view, which is now part of the trusted computing base along with the manager VM; a bug in that code breaks the guarantee, and side-channel attacks are explicitly out of scope, so this is memory isolation against a malicious kernel, not a defence against every class of attack.
• The programming model has real constraints. Code in the sub view cannot call standard libraries that make system calls, since there is no system-call support there, and the guest must disable interrupts before entering the gate — done by letting a user-space process control the interrupt flag, which is reasonable for a VM dedicated to one application but a compromise otherwise.
• The application gains are much smaller than the microbenchmark ones. The headline 163 percent is best-case inter-VM networking throughput with no physical device in the path; real application results are more modest — 11 percent lower tail latency for an HTTP server, 42 percent for memcached — and over a physical card, large packets erase the gap entirely because the card’s bandwidth, not the crossing, is the limit.
• The networking use case has a fairness wrinkle. A guest’s own CPU cycles are spent forwarding packets that arrived for other guests, which can be unfair; it is fixable with a dedicated polling thread in the manager VM, but that trades away CPU efficiency.
• The evaluation hardware is modest and dated. The premise is that CPUs are not keeping pace with fast I/O, yet the testbed uses Haswell-era Xeons and 10-gigabit cards; how the per-access overhead behaves at 100 gigabits and beyond, where it would matter most, is not shown.
• The prototypes are proofs of concept. The virtual switch is a roughly 250-line learning bridge and the key-value store a simple hash table, enough to demonstrate the model but not production systems, so the numbers show potential rather than deployed behavior.

The evaluation

Check yourself

Sources

The paper is “Exit-Less, Isolated, and Shared Access for Virtual Machines” by Kenichi Yasukata, Hajime Tazaki, and Pierre-Louis Aublin, published at ASPLOS 2023, pages 224-237, DOI 10.1145/3582016.3582042. The authors are at IIJ Research Laboratory, Japan.

This explainer is written from the full 14-page text. Everything above comes from the paper’s own sections: the introduction and background contrasting direct mapping and host interposition and their isolation-versus-overhead trade, the extended page table and its role as the host’s memory-access control, and VMFUNC EPTP switching with its measured 130-nanosecond round-trip against a 699-nanosecond hypercall; the threat model treating the guest kernel as untrusted; the challenges section quantifying the page-table-maintenance overhead (the 26-times getpid slowdown from trapping the page-table register, and the 805-nanosecond cost of per-switch register updates) and the entry-point-bypass attack, with the table of prior VMFUNC systems that solve only one of the two; the design section presenting the three EPT contexts, the Anywhere Page Table with its duplicated-root construction, and the gate EPT context with its dynamic switch-list manipulation and self-check, plus the discussion of Intel VT-rp as an alternative; the programming model with the manager VM, the roughly 200-line KVM hypercalls and 1200-line libelisa, and the shared-memory, interrupt, and negotiation mechanisms; and the evaluation and use cases reporting the 196-nanosecond crossing and 3.5-times advantage, the count-up scalability, and the VM networking system (54 and 49 percent higher physical-NIC RX and TX, 39 to 163 percent inter-VM, and the Seastar HTTP and memcached latency results) and the in-memory key-value store (58 to 64 percent higher GET and 33 to 39 percent higher PUT throughput).