On Mon, Jun 27, 2022 at 08:12:08AM -0400, Neal Gompa wrote: > On Mon, Jun 27, 2022 at 7:59 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > On Mon, Jun 27, 2022 at 07:46:29AM -0400, Neal Gompa wrote: > > > On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > > > > > On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote: > > > > > On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour > > > > > <demiobenour@xxxxxxxxx> wrote: > > > > > > > > > > > > On 6/25/22 07:56, Roberto Ragusa wrote: > > > > > > > On 6/19/22 22:54, Sharpened Blade via devel wrote: > > > > > > > > > > > > > >> Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. > > > > > > > > > > > > > > How big is the demand for this kind of lockdown? > > > > > > > As a since-last-century Linux user, I'm choosing Fedora > > > > > > > exactly to NOT have all this signing/trusted boot > > > > > > > complications on my systems and I do not see a reason > > > > > > > to turn Fedora into Android (or, worse, iOS). > > > > > > It’s necessary for secure boot to actually be meaningful in > > > > > > practice. I expect that people who care about secure boot > > > > > > will want this. > > > > > > > > > > I don't. I only care about secure boot enough to bootstrap a Free > > > > > platform. Secure Boot is generally not designed as a tool to provide > > > > > security unless you rip out all the certs and use your own > > > > > exclusively. At that point, you can do whatever you want. > > > > > > > > > > Most PCs are poorly designed to handle doing this procedure, and it's > > > > > too easy to accidentally break the computer entirely by doing so. It's > > > > > just not worth it. > > > > > > > > > > I treat Secure Boot purely as a compatibility interface. We need to do > > > > > just enough to get through the secure boot environment. > > > > > > > > Many of the same issues & concepts from Secure Boot are involved in > > > > confidential virtualization technology. This provides mechanism to > > > > boot virtual machines on public cloud hosts, with strong protection > > > > against a malicious host OS user snooping on what's going on in your > > > > VM. You establish a trust relationship with the CPU hardware/firmware, > > > > and once verified you can be confident the VM is booted with the guest > > > > firmware, bootloader, kernel, initrd, cmdline that you deployed. This > > > > will close one of the biggest security gaps between public cloud and > > > > running on hardware you own & control yourself, so will be relevant > > > > to anyone who uses cloud. Being able to improve kernel/initrd/cmdline > > > > handling for SecureBoot will be beneficial for confidential computing, > > > > and vica-verca. > > > > > > > > > > That's flawed. As long as you don't control the hypervisor stack, you > > > can't establish a trust relationship. Confidental computing is > > > fundamentally broken in the public cloud because the public cloud > > > provider can do whatever it wants to the hypervisor stack. If it was a > > > private cloud infrastructure you ran, that's a different story. > > > > No, that is not the case, what you describe is the traditional > > virtualizaton scenario, where hypervisor "root" is all-powerful > > over everything, with no way to limit that that can be trusted by > > guest owners. Confidential computing (for example AMD's SEV-SNP > > or Intel TDX) is about using new CPU hardware & firmware features > > to prevent the cloud provider from doing whatever they like. It > > further provides a way for the guest owner to cryptographically > > validate this is the case at boot time, such that the VM owner > > can ensure it will not boot if the host admin tampered with the > > requested execution environment. There is a decent overview of > > threats that SEV-SNP aims to protect against here: > > > > https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf > > > > Why are you assuming that can't be faked? We can fake secure enclaves > for virtualization, there's no reason that can't be faked too. Generating the expected cryptographic measurements requires access to the right keys for signing data to establish the root of trust back to the CPU vendor. There will always be attack vectors against the firmware since no software is ever bug free. The designs take account of that by including the host firmware when validating the VM state, so the guest owner can reject known flawed older firmware versions. This really is a massive step forwards in virtualization technology and not an easy thing to defeat. 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 on the list, report it: https://pagure.io/fedora-infrastructure
