On Mon, Jun 27, 2022 at 7:59 AM Daniel P. Berrangé <berra...@redhat.com> 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é <berra...@redhat.com> > > 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 > > > > <demioben...@gmail.com> 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
