Devlore: Device Interrupt Protection for Confidential VMs

arXiv:2408.05835 · cs.CR · Submitted 2026-08-11 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "Devlore: Device Interrupt Protection for Confidential VMs".

Jane: The paper was written by Andrin Bertschi, Supraja Sridhara, Mark Kuhne, Benedict Schlüter, Friederike Groschupp et al. from ETH Zurich.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Title and Authors: Tom: Welcome back, everyone! Tom here, and I’ve got Jane with me, and we are absolutely buzzing about this one. Today we’re digging into “Devlore: Device Interrupt Protection for Confidential VMs” from ETH Zurich.

Jane: And I have to say, Tom, the title alone got me excited. “Device Interrupt Protection” – that sounds super specific, but it’s actually tackling a huge blind spot in confidential computing.

Tom: Right? We hear all about encrypting memory and isolating VMs, but what happens when a device needs to talk to that VM? That’s where the magic – or the trouble – starts.

Jane: Exactly. So, the team behind this – Andrin Bertschi, Supraja Sridhara, and a whole crew from ETH – they’re basically saying, “Hey, we’ve locked the front door, but the window is wide open.” And that window is interrupts.

Tom: For our listeners who aren’t deep in the weeds, an interrupt is basically a device tapping the CPU on the shoulder. Like, “Hey, I’m done with that job,” or “Hey, you’ve got a key press here.”

Jane: And in a confidential VM, you’re supposed to be safe from the hypervisor – the software that manages all the VMs. But the hypervisor is the one that handles these interrupts. So, it can fake them.

Tom: It’s like having a security guard who’s supposed to protect your house, but he’s also the one who can knock on your door pretending to be the pizza guy, over and over, just to mess with you.

Jane: And that’s not just annoying. The paper shows that a fake interrupt can trick a driver into thinking a device is ready when it isn’t, or increment a counter that triggers an event. It breaks the integrity of the whole system.

Tom: So the title is really about closing that window. “Devlore” – I love that name, by the way – is their solution to make sure that when a device interrupts a CVM, it’s the real deal.

Jane: And they do it without changing the device drivers or the apps, which is a huge deal. We’re talking about a system that works with the existing Linux kernel and hardware, just with some smart checks in the trusted software.

Tom: I’m already on the edge of my seat. They’re not just pointing out the problem; they’ve built a prototype on Arm’s Confidential Computing Architecture.

Jane: Right, and that’s where the real meat is. Let’s get into how they actually pulled this off.

Summary: Tom: So, Jane, we’ve got the problem – malicious interrupts. Now, how does “Devlore: Device Interrupt Protection for Confidential VMs” actually solve it? Because I know you’ve been reading the details.

Jane: It’s a “delegate-but-check” strategy, which is a fancy way of saying they let the hypervisor do its job, but they put a trusted bouncer in the room to check every move.

Tom: A bouncer that checks IDs. I like it. So, what’s the first step?

Jane: First, they stop the hypervisor from writing directly to the interrupt controller – the GIC, in Arm terms. They move that configuration into the “root world,” the most trusted part of the system. So, if the hypervisor wants to change anything, it has to ask the monitor, the trusted firmware, to do it.

Tom: So, no more faking physical interrupts by just flipping a bit in the hardware.

Jane: Exactly. But that’s only half the battle. The hypervisor can still inject *virtual* interrupts into the CVM. So, Devlore records every real, physical interrupt that comes from a device. That record is the “ground truth.”

Tom: So, it’s like a log of all the legitimate knocks on the door.

Jane: Precisely. Then, when the hypervisor wants to inject a virtual interrupt, the trusted Realm Management Monitor – the RMM – checks that log. If there’s no matching physical interrupt, the injection is blocked.

Tom: But it’s not just a simple count, is it? I saw something about ordering and priority in the paper.

Jane: You’re right. A malicious hypervisor could take a real interrupt for a low-priority event and pretend it’s a high-priority one, or reorder them to mess with the guest OS. So, Devlore checks the order and the priority of the interrupts against that ground truth log.

Tom: So, it’s not just “did an interrupt happen?” It’s “did *this* interrupt happen, in *this* order, with *this* priority?”

Jane: That’s the gist of it. And they do all this without changing the device drivers, which is the killer feature. They tested it with a GPU, a UART, a keyboard, and even LEDs.

Tom: That’s impressive. But I’m wondering about the cost. All this checking has to slow things down, right?

Jane: That’s the million-dollar question, and that’s what we’re going to dig into next, because their numbers are surprisingly good.

Improvements and Evaluation: Tom: So, Jane, we’ve established the *what* and the *how*. Now, let’s talk about the *so what*. What’s the actual cost of all this security?

Jane: That’s the best part, Tom. The overhead is almost nothing. They ran a full GPU benchmark suite – glmark2 – which is a typical integrated GPU workload, and the slowdown was just zero point zero six percent.

Tom: zero point zero six percent? That’s basically free. I was expecting a horror story about performance.

Jane: Right? And even under a sustained interrupt stress test, they saw overheads of only about one percent. That’s on a real Arm board, the Rock 5B, which is a pretty solid indicator that this is practical, not just a lab experiment.

Tom: And they didn’t just test performance. They actually tried to attack it. They wrote malicious code to inject fake virtual and physical interrupts, and Devlore blocked all of them.

Jane: That’s the part I love. They didn’t just say “trust us.” They built the attacks and showed the system stopping them. It’s a really thorough evaluation.

Tom: So, what’s the big improvement here compared to what we had before? Because I feel like this is a fundamental shift.

Jane: Before, the hypervisor had total control over the interrupt lifecycle. Now, Devlore takes that control and puts a trusted layer in between, without rewriting the whole world. It’s a surgical fix.

Tom: And it’s not just for one specific device. They showed it working with four different types of devices, which suggests it’s a general solution.

Jane: Exactly. It’s a general mechanism for interrupt isolation, not a one-off hack. That’s what makes it so impactful. It means we can finally attach real, integrated devices to confidential VMs without worrying about the hypervisor messing with them.

Tom: I’m curious to hear what the rest of the team thinks about the broader implications. Let’s bring in Lu and Meng.

Lu: I’m really excited about the “delegate-but-check” philosophy. It’s a pattern we’re going to see more of in confidential computing. Instead of trying to remove the untrusted component, you just verify its outputs. It’s a much more scalable approach.

Meng: And from a practical standpoint, the fact that they kept the changes to about seven thousand five hundred lines of code across the hypervisor, firmware, and kernel is huge. That’s a manageable patch for a real system to adopt.

Tom: So, it’s not just a theoretical idea; it’s something that could actually be deployed. That’s a win.

Conclusion: Tom: Alright, we’re wrapping up our look at “Devlore: Device Interrupt Protection for Confidential VMs.” Jane, give us the final word.

Jane: The final word is that this paper closes a critical gap. We’ve been protecting CVM memory for a while, but the interrupt path was left wide open. Devlore shows us a way to lock it down without sacrificing performance or compatibility.

Tom: And they did it with a clever design and a thorough evaluation. They didn’t just theorize; they built it, broke it, and showed it works.

Jane: It’s a big step towards making confidential computing actually usable for real-world applications that need integrated devices, like GPUs and sensors.

Tom: So, from ETH Zurich, we’re saying goodbye to “Devlore.” It was a fantastic paper, and we’re excited to see where this research goes next.

Jane: Absolutely. Thanks for listening, everyone. We’ll be back with another paper soon.

Tom: Until next time, keep your interrupts authentic.

Jane: And your VMs confidential. See you later!

Andrin Bertschi, Supraja Sridhara, Mark Kuhne, Benedict Schlüter, Friederike Groschupp, Clément Thorens, Nicolas Dutly, Srdjan Capkun, Shweta Shinde

ETH Zurich

cs.CR

Submitted: 2026-08-11

Comments: Two-column extended version of the paper published at RAID 2026. This version supersedes previous arXiv versions

Project page: https://sectrs-devlore.github.io

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 77/100

The gist: Devlore is a device interrupt isolation mechanism that protects confidential VMs (CVMs) from interrupt manipulation attacks on Arm Confidential Computing Architecture (CCA).

Key concepts

Confidential VMs (CVMs): These are isolated virtual machines designed to be secure from the hypervisor, the software that manages them. The paper focuses on protecting these environments when a device needs to communicate with them.
Malicious Interrupt Injection: This is a security threat where a malicious hypervisor fakes physical interrupts or reorders and changes their priority. This can trick device drivers, breaking the integrity of the system by controlling the interrupt lifecycle.
Devlore (Delegate-but-Check): This is a security strategy where a trusted monitor verifies all actions taken by an untrusted hypervisor. It ensures that when a device interrupts a CVM, the interrupt is genuine, without rewriting existing code.
Ground Truth Log: Devlore records every real, physical interrupt coming from a device in this log. When the system receives a virtual interrupt injected by the hypervisor, the trusted monitor checks this record to confirm if a corresponding physical event occurred.

Terminology

Core — 23× in this paper · explained in 2 episodes
Benchmark — 11× in this paper · explained in 2 episodes
Abstraction — 4× in this paper · explained in 1 episode
Arm Confidential Computing Architecture — 4× in this paper
Verification — 4× in this paper · explained in 2 episodes
Realm Management Monitor — 3× in this paper
Arm Fixed Virtual Platform — 2× in this paper
Realm Management Extensions — 2× in this paper
Trace — 2× in this paper · explained in 2 episodes
Arm TrustZone — 1× in this paper · explained in 1 episode
Cooperation — 1× in this paper · explained in 2 episodes
Edge Devices — 1× in this paper · explained in 2 episodes
Generic Interrupt Controller — 1× in this paper
Granule Protection Checks — 1× in this paper
Realm Management Interface — 1× in this paper
Realm Service Interface — 1× in this paper
Secure Monitor Call — 1× in this paper

Summary

Devlore is a device interrupt isolation mechanism that protects confidential VMs (CVMs) from interrupt manipulation attacks on Arm Confidential Computing Architecture (CCA). The paper states: "We present Devlore, a device interrupt isolation mechanism that protects confidential VMs from interrupt manipulation attacks. Our design employs a delegate-but-check strategy by offloading interrupt management to the hypervisor, but adds correctness checks in the trusted software."

The problem is that an attacker can inject malicious interrupts to break the confidentiality and integrity of confidential VMs. The paper notes that recent works have shown that interrupt attacks from a malicious hypervisor can compromise the CVM execution. The threat model assumes the platform and all of its components, including the interrupt controller (GIC) are trusted, while all software executing in the normal and secure worlds is untrusted. The goal is to ensure that the device interrupts delivered to a CVM in the presence of an untrusted hypervisor is equivalent to interrupts that would be delivered if the hypervisor was trusted.

The design proceeds in three steps. First, Devlore prevents malicious GIC writes: "Devlore stops the hypervisor from directly writing to the GIC memory by marking the GIC memory as root world and using the monitor to check any updates to the GIC configuration. This ensures the physical interrupt authenticity, i.e., any physical device interrupt that arrives at the cores is guaranteed to only be from the device. Second, Devlore records physical interrupts: the monitor records the physical interrupt in a realm data structure... This data structure serves as the ground truth for virtual interrupts. Third, Devlore checks virtual interrupts: the RMM rigorously checks that the virtual interrupt injection is benign... the RMM looks up the data structure with authentic physical interrupts from the monitor... Thus, Devlore ensures that the hypervisor cannot inject arbitrary virtual interrupts while preserving ordering and interrupt priorities."

The paper details the checks performed by the RMM. Check #2 ties the authenticity of the physical interrupts to the virtual interrupts by requiring the monitor to write the registered physical interrupt numbers that arrive to a list in realm memory. Check #3 ensures ordering: the RMM uses the monitor ordered list to check ordering with a window size of n where n is the number of distinct interrupts the vGIC can inject at once. Check #4 ensures priorities: "the RMM uses this information to create per-CVM ordered priority lists and checks the virtual interrupt injections from the hypervisor against them, so that the hypervisor always injects the highest-priority pending interrupts. Together, checks #2, #3, and #4 achieve Devlore interrupt isolation."

The implementation is on the Arm Fixed Virtual Platform (FVP) and a Rock 5B board using OpenCCA. The paper reports: "We prototype our design, called Devlore, on the Fixed Virtual Platform (FVP), a CCA-enabled emulator provided by Arm to demonstrate feasibility, correctness, and compatibility with hardware specification and software stack. The changes are minimal (≈7.5k LoC), and without device driver changes. Specifically, 3054 LoC in the trusted firmware v2.8 (TF-A) which we use as the monitor, 1188 LoC in RMM v0.2.0, and 2706 LoC in the Linux kernel v6.2.0."

The evaluation covers functionality, security, and performance. On the FVP, Devlore is tested with four devices of varying complexity and isolation requirements: GPU, UART, Keyboard/Mouse, and LEDs/Buttons. The security evaluation validates four checks: benign interrupts reach the CVM correctly; malicious virtual interrupts injected by the hypervisor are rejected; malicious physical interrupts via GIC writes are blocked; and malicious memory accesses to device MMIO are rejected. On the Arm board, the paper reports: under sustained interrupt load, Devlore only incurs overheads up to 1%. For the glmark2 GPU benchmark, Devlore overhead drops to only 0.06%. The paper concludes: Our case studies show the feasibility of real-world use cases and that Devlore incurs minimal overheads of 0.06% for typical integrated GPU applications.

Improvements for AI systems

Based on the scientific paper, here are specific improvements I can make to AI systems and what the improved AI systems can do:

Improvement: Integrate Devlore's interrupt isolation mechanism into AI inference pipelines that use integrated GPUs (e.g., Mali, Adreno) within confidential VMs.

What the improved AI system can do:

Run sensitive AI inference (e.g., biometric authentication, medical diagnosis) on integrated GPUs inside confidential VMs without risk of malicious interrupt injection from an untrusted hypervisor
Guarantee that GPU job-completion interrupts delivered to the AI application are authentic and cannot be forged to trigger false inference completion or corrupt model state
Maintain AI inference integrity even when the hypervisor is compromised, ensuring that interrupt-based attacks cannot alter the AI model's execution flow

Improvement: Apply Devlore's interrupt isolation to AI accelerators that require firmware loading (like the WCNSS example in the paper).

Improvement: Use Devlore's counter-interrupt protection (as demonstrated with the Linux counter subsystem) for AI systems that rely on event-driven triggers.

Improvement: Leverage Devlore's device attach/detach and interrupt registration mechanisms for AI systems that manage multiple integrated devices.

Improvement: Apply Devlore's low-overhead design (0.06% overhead for GPU workloads) to AI systems that require both security and performance.

Improvement: Use Devlore's security evaluation methodology to build AI systems that can be verified against interrupt-based attacks.

Improvement: Adopt Devlore's delegate-but-check strategy for AI systems that require both flexibility and security.

These improvements enable AI systems to operate securely in confidential computing environments, particularly on Arm CCA platforms, with guaranteed interrupt integrity, minimal performance overhead, and protection against sophisticated interrupt-based attacks.