Devlore: Device Interrupt Protection for Confidential VMs

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!