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. -- 真実はいつも一つ！/ 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
