On Wed, Dec 21, 2022 at 03:31:10AM +0100, Kevin Kofler via devel wrote: > PS (adding to my previous reply): > > Daniel P. Berrangé wrote: > > The immediate need for UKIs is indeed related to SecureBoot and > > TPMs. These are a core technology foundation of the confidential > > virtual machine stack. On Azure today, if you request an Ubuntu > > confidential VM, Azure will pre-encrypt the root filesystem and > > So basically this change proposal is about supporting a feature of the > Microsoft cloud platform (Azure) in Fedora and will be pretty useless to any > user not using Microsoft's platform. No it is not useless. Most major public public clouds have support for running VMs with SecureBoot and TPMs, which they typically refer to as "Trusted Boot". Fedora (and Linux in general) support for this is a pretty poor from a security POV since the initrd is not covered by the signature. Making use of UKIs allows building VMs that take proper advantage of Trusted Boot to allow data to be secrely sealed to the TPM. The Azure confidential VMs feature is something that then builds on top of Trusted Boot, to provide confidentiality against a malicious hypervisor OS/admin. I mention Azure because it is first to ship something in this space. We are also working on confidential VMs for KVM, which will likewise use Trusted Boot as a foundation for the boot process. So we will have a fully open source hypervisor stack that can take advantage of UKIs in Fedora. I can't promise any timeframe to deliver it in Fedora yet, though probably not F38. Maybe some bits in F39 if everything aligns. Overall our goal is to make "confidential VMs" into a boring feature that "just works" without users needing to understand the technology details (unless they really want to, or have specific extra requirements for verification). We want to be able to build a VM disk image that is capable of booting in a guest using legacy BIOS, or UEFI, or UEFI with SecureBoot + TPM, or UEFI with SecureBoot + TPM + Confidential VM. This is one of the reasons for adding UKI support to grub. The complex bits are all to be handled by the OS / hypervisor vendors, not made into a burden no the end users. > > seal the LUKS key against predicted TPM PCR values. It guarantees > > that the root disk can only be decrypted by the specific VM > > instance that is requested, when it is running in SecureBoot > > mode with the expected measurments on AMD SEV-SNP confidential > > hardware. > > Does it really guarantee that, and not just that it can only be decrypted by > any VM using the same UKI? The root disk has to be encrypted for *each* instance of the VM, because you can't have the LUKS primary key shared beween instances. Similarly each VM has to have a distinct TPM with its own keys. When you seal the LUKS passphrase using keys associated with one TPM, its impossible to unseal using the TPM from any other VM. The signed UKI is needed so that the initrd is running trustworthy code, to ensure it is not stashing a copy of the LUKS passpharse some an attacker can then access. > How reliably does it ensure that the user can only get root in the decrypted > image with the root password (or SSH key or similar) stored inside the image > and not through some other means? There is a challenge with the way tools like cloud-init traditionally work, because the data they inject into the guest, is marshalled by the hypervisor. This hypervisor is considered untrustworthy in a confidential compute environment. Thus the runtime injection of the SSH key to the VM is dubious. So I can't claim every attack vector is solved yet with confidential VMs. People are working to incrementally tackle different pieces. Most likely it will either involve a different channel that cloud-init, or will involve providing signatures over cloud-init data that can be securely verified, to prove the right SSH key is injected. > In the end, if you store data on a "cloud", you are storing it on other > people's computers. You are also relying on their confidentiality > guarantees. How can you trust the "cloud" provider to actually perform the > encryption steps they claim to perform when you check that checkbox, and > also to not have a backdoor (such as a fixed master key in an extra LUKS key > slot, or a custom, possibly software-emulated, TPM that does not actually > keep the key sealed) that allows them to decrypt anything anyway? There are theoretically ways to prove this, but it is getting quite complicated to go into much detail, so I'll make two general points. First there is a difference between trusting the hypervisor and trusting the cloud vendor. Even if you still need to trust the cloud vendor, it is beneficial to be able to distrust their individual compute hosts. If a VM manages to break out into the host, this gives protection to your VM that doesn't exist in traditional virtualization environments. Being able to distrust the cloud vendor entirely is a subsequent logical step. I think that open source should be a better position here, since being able to verify the source running on the cloud, and have reprodicable builds are a key part to establishing confidence. The disk image encryption stuff would have to be verifiable & reproducible, and itself be running inside a confidential VM that the user can verify, to avoid the possibility of the cloud owner backdooring it. Hard but by no means impossible, and what we want to achieve with KVM eventually. > You are handing off your data to a third party and then trying to rely on > Treacherous Computing technologies preventing that third party from doing > some things (such as copying the encryption key) on their own computers. I > do not think that this is in either party's interest. Compare with the current state of public cloud, where you hand off your data to a third party and have no guarantees about anything, just have to blindly trust all of the hardware and software and vendor. With confidential VMs we're incrementally reducing the amount of trust needed on the vendor/software, by taking advantage of the hardware. Hardware (and its associated firmware) of course is not foolproof, but users already trust the hardware today. Ultimately some people will be paranoid enough they'll never use public cloud for certain workloads. Confidential VMs may move the needle such that some more workloads become appropriate for public cloud, while also giving greater protection to workloads that are already using public cloud. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
