Matthew GarrettMy annual plea for a thing: I want a type 1 hypervisor that just has a small isolated VM and then passes through the rest of the hardware to the main VM which runs Linux. The small VM is intended to be used to run small pieces of code that the main OS should not be able to interfere with. Does such a thing exist? (Think Xen, but with a Dom0 that can't see into DomUs)
bEA đ@mjg59 you missed "in an ssh-agentâ.
Stephen Crane@mjg59 youâve looked at halfnium for this? https://hafnium.googlesource.com/hafnium/+/HEAD/docs/Architecture.md
Zimmie
ĐĐ°ĐźŃĐ°Đ˝ ĐоОŃгиовŃки
Gaveen Prabhasara@mjg59 doesn't quite sound like what Qubes OS is doing
Howard Chu @ Symas@mjg59 sounds like something you'd need Secure Encrypted Virtualization for https://www.amd.com/en/developer/sev.html
@hyc No, once you're in SEV-land you're not really in a good place to do hardware passthrough
@mjg59 hm, that's a tough one then, maintaining isolation.
@hyc I'm fine with the hypervisor being able to see what's happening in arbitrary guests, but there needs to be isolation between the primary VM and the security VM (Hyper-V manages this fine in Windows land)
Florian Idelberger
baloo
Morten LinderudI suspect this is a continuation of the fingerprint issue Matthew was writing about a couple of months(?) ago.
EDIT: This post https://nondeterministic.computer/@mjg59/111456696748600420
Matthew Garrett (@[email protected])
https://blackwinghq.com/blog/posts/a-touch-of-pwn-part-i/ is some very nice research, with some terrifying takeaways: 1) Microsoft developed a secure communications path between the OS and any biometric devices 2) One vendor used the same backing store for both the secure and insecure path, allowing enrollment of fingerprints via the insecure path that were then trusted in the secure path 3) Another vendor used their own fucked up TLS-based implementation rather than the Microsoft one 4) *Microsoft* didn't use their own protocol
@mjg59 @hyc
I know you already dismissed SEV, but https://github.com/project-oak/oak seems vaguely related?
This is a VM inside the main OS, but the binary inside the TEE is available over grpc.
Jonathan McDowell
Alexander Graf@mjg59 sounds pretty close to Jailhouse?
@agraf My recollection is that Jailhouse does static partitioning and no scheduling, ie you need to give it a CPU? It also starts from Linux which makes it harder to sequester secrets that Linux can't get at.
@mjg59 I'm not sure how much both of these are embedded into its architecture or just artifacts of how its main users consume it.
@agraf I'm pretty sure the lack of scheduling is a design choice that would need to be retrofitted. Launching from Linux is more about how it's managed, so that's probably an easier thing to fix.
@mjg59 true, it doesn't seem to support any scheduling at all. That said, I'd expect a simple round robin scheduler may not be super difficult to implement. Either way, not an off the shelf solution for your use case.
Fi đłď¸ââ§ď¸@mjg59 is this like, kind of a secure enclave/hsm-equiv situation you're looking for?
@munin Yeah, like Windows does with Credential Guard
Simon Bisson
bluca@mjg59 there's work in progress by @l0kod but don't think it's merged yet: https://lore.kernel.org/all/2024050313[email protected]/
MickaĂŤl SalaĂźn@mjg59 @bluca kind of, Heki is the equivalent of Windows's Virtualization Based Security (foundation of Credential Guard and other security mechanisms) for Linux (with KVM or Hyper-V). The host/VMM is part of the TCB like the hypervisor, but the Linux guest VM requests the hypervisor to protect itself (guest). For now this is only CR-pinning (v3) and memory permissions (v2). We could probably implement the same mechanism with Jailhouse, but that would remove a lot of VM use cases
Adam Hawkes@mjg59 Like Proxmox? Or maybe I have it backwards.
4censord 
@mjg59 maybe check on kata and firecracker.
These are container engines and not really made for you usecase, but they do run a minimal system Linux, and then run your applications in isolated mini VMs.
Maybe some of their tech can be addapted
These are container engines and not really made for you usecase, but they do run a minimal system Linux, and then run your applications in isolated mini VMs.
Maybe some of their tech can be addapted
Mark Esler
đŚnewđ§ FireFly@mjg59 I don't think it's in a usable state yet (at least for x86 hosts, according to their FAQ), but I think seL4-as-hypervisor would fit the bill otherwise from my understanding
cf. https://docs.sel4.systems/projects/sel4/frequently-asked-questions.html#how-good-is-sel4-at-supporting-virtual-machines
& https://sel4.systems/About/seL4-whitepaper.pdf
Tobias@mjg59 So Qubes one step further?
keen456
keen456
Emelia/Emi@mjg59 So basically "a programmable HSM" like a less-locked-down version of apple's secure enclave? I honestly think trying to achieve secure isolation on the same CPU as the rest of the OS is a fool's game, and the only way to ensure isolation is to physically isolate things onto independent cores via a mailbox interface.
(I've wanted something similar for literally ever...)
@becomethewaifu Hypervisors are "good enough", given that we haven't seen multi-tenant cloud turn into a complete disaster
Graham Sutherland / Polynomial@mjg59 a concept like SGX enclaves / LSASS isolation but actually accessible and convenient to use would be very nice.
Chip Collier@mjg59 acrn? https://projectacrn.org but also I think xen can also do this.
Kensan@mjg59 Itâs more or less how I use/dogfood Muenš. What makes it not usable in your case is probably static partitioning and highly target hardware dependent.
Would you mind elaborating a bit what the rest of your envisioned system looks like?
__
š https://muen.sk
Would you mind elaborating a bit what the rest of your envisioned system looks like?
__
š https://muen.sk
@mjg59 To be sure I understand, you want a small VM and a big VM. The big VM gets all the hardware minus whatâs needed to run the hypervisor and the small VM. Communications between the big VM and the small VM are strictly controlled in both directions such that neither can interfere with the other.
What sort of thing are you trying to do with this small VM?
This sounds kind of like what a TPM is for, or maybe a BMC/SMC/LOM.
@bob_zim Manage secrets in ways that the TPM can't (eg, the TPM can't establish a secure communications channel with a biometric reader)
@mjg59 So the small VM would own the physical link to the biometric reader, then provide its own attestation about the biometric readerâs attestation it was presented an authentic biometric?
Hmm. Iâm not sure I know of a way to do that in software. Decent biometric readers should already use asymmetric keys, though. It should be possible to get a secure element like a TPM or smart card to only unlock a stored key when presented with a valid signature from the readerâs private key.
@bob_zim No need for a physical link (eg, TLS is secure without you having to trust the physical link, modern biometric devices implement equivalent functionality). It is not possible to use a TPM in this way given the hardware that exists.
@mjg59 Thatâs what Iâm getting at: decent biometric readers should already use asymmetric keys. You may not be able to hook that directly to an off-the-shelf TPM, though I thought some had firmware allowing them to trust external public keys for exactly this reason. Might require writing custom RoT firmware like Oxide has done.
A guest can never keep a secret from the hypervisor under which it runs. The host always has full control over the guest, including the ability to inspect and change stack frames. At that point, youâre guaranteed to have a single piece of software which can get at both the clear key material from the small VMâs RAM and the data the key controls from the big VM.
Assuming thatâs what youâre trying to prevent, I donât know of any software system I would trust to provide sufficient isolation between the guests, even at a theoretical level. Computer-in-a-computer stuff like a TPM is it.
@bob_zim I can't rewrite the firmware for my TPM, so that's not a viable approach. I also trust the hypervisor. What I want is to not trust Linux.
NicolĂĄs Alvarez@nicolas17 @mjg59 Then just use dom0 instead of the small VM. Thatâs easy. The hypervisor can keep secrets from a guest. Thatâs an obvious solution, though, which is why I wanted to clarify the requirements.
@bob_zim @nicolas17 But then it's massively harder to plumb all my hardware (including ACPI) into a domu
@mjg59 @nicolas17 So is the goal something like a software secure element for workstation use?