I have become curious about confidential computing.
Does anyone have much idea about the current status of this feature? I found security.sev.session.dh which looks very promising, and some threads here and there in this forum.
Is it viable at this point to give people the capability to run snoop/tamper-proof VMs (preferably with Incus, but I can use something else) in a way where they can validate those properties?
I think full confidential computing is still a bit of a pipe dream at this stage, not just with Incus but in general. That’s not to say that features like AMD SEV aren’t valuable on their own though!
Incus indeed has basic AMD SEV and SEV-ES support which allows for using memory encryption and seeding some specific keys as part of the instance configuration.
When I’m saying that confidential computing is still a bit of a pipe dream, I mostly refer to a lot of extra complexity both on the consumer side in preparing a suitable image and knowing exactly how to verify it when running it in an untrusted environment but also just on the technical side as you really need to ensure that your guest OS doesn’t react to a variety of events and data that may be coming from a compromised hypervisor.
I’ve attended quite a few talks at various conferences where time and time again, it’s shown just how easy it is to miss a tiny bit of attack surface here and there in the kernel, with potentially disastrous consequences if actually running in a hostile environment
Ah, so you mean things like incus exec from an administrator could operate on an encrypted VM? (Maybe not that, but similar things, I guess.)
Yeah, that makes sense.
I guess the encryption of the image preparation could be automated in whatever image preparation tools you want to use. And hopefully at some point there would be an incus verify that could give some certainty.
However, that’s the input I needed- I will shelve this for now, thanks!
Right, the guest agent is something you’d definitely want to disable inside the guest if running in an untrusted environment.
But the more problematic issues are things like ACPI events sent from the Hypervisor, injecting data through the CPUID tables, … basically a bunch of things that the kernel reads at various times which can be altered by the Hypervisor and used to attack an otherwise protected guest.
