On Thu, Sep 08, 2022 at 02:28:29PM +0200, Ard Biesheuvel wrote: > On Thu, 8 Sept 2022 at 13:30, Laszlo Ersek <ler...@redhat.com> wrote: > > > > On 09/06/22 13:33, Daniel P. Berrangé wrote: > > > On Tue, Sep 06, 2022 at 01:14:50PM +0200, Ard Biesheuvel wrote: > > >> (cc Laszlo) > > >> > > >> On Tue, 6 Sept 2022 at 12:45, Michael S. Tsirkin <m...@redhat.com> wrote: > > >>> > > >>> On Tue, Sep 06, 2022 at 12:43:55PM +0200, Jason A. Donenfeld wrote: > > >>>> On Tue, Sep 6, 2022 at 12:40 PM Michael S. Tsirkin <m...@redhat.com> > > >>>> wrote: > > >>>>> > > >>>>> On Tue, Sep 06, 2022 at 12:36:56PM +0200, Jason A. Donenfeld wrote: > > >>>>>> It's only safe to modify the setup_data pointer on newer kernels > > >>>>>> where > > >>>>>> the EFI stub loader will ignore it. So condition setting that offset > > >>>>>> on > > >>>>>> the newer boot protocol version. While we're at it, gate this on SEV > > >>>>>> too. > > >>>>>> This depends on the kernel commit linked below going upstream. > > >>>>>> > > >>>>>> Cc: Gerd Hoffmann <kra...@redhat.com> > > >>>>>> Cc: Laurent Vivier <laur...@vivier.eu> > > >>>>>> Cc: Michael S. Tsirkin <m...@redhat.com> > > >>>>>> Cc: Paolo Bonzini <pbonz...@redhat.com> > > >>>>>> Cc: Peter Maydell <peter.mayd...@linaro.org> > > >>>>>> Cc: Philippe Mathieu-Daudé <f4...@amsat.org> > > >>>>>> Cc: Richard Henderson <richard.hender...@linaro.org> > > >>>>>> Cc: Ard Biesheuvel <a...@kernel.org> > > >>>>>> Link: > > >>>>>> https://lore.kernel.org/linux-efi/20220904165321.1140894-1-ja...@zx2c4.com/ > > >>>>>> Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> > > >>>>> > > >>>>> BTW what does it have to do with SEV? > > >>>>> Is this because SEV is not going to trust the data to be random > > >>>>> anyway? > > >>>> > > >>>> Daniel (now CC'd) pointed out in one of the previous threads that this > > >>>> breaks SEV, because the image hash changes. > > >>>> > > >>>> Jason > > >>> > > >>> Oh I see. I'd add a comment maybe and definitely mention this > > >>> in the commit log. > > >>> > > >> > > >> This does raise the question (as I mentioned before) how things like > > >> secure boot and measured boot are affected when combined with direct > > >> kernel boot: AIUI, libvirt uses direct kernel boot at guest > > >> installation time, and modifying setup_data will corrupt the image > > >> signature. > > > > > > IIUC, qemu already modifies setup_data when using direct kernel boot. > > > > > > It put in logic to skip this if SEV is enabled, to avoid interfering > > > with SEV hashes over the kernel, but there's nothing doing this more > > > generally for non-SEV cases using UEFI. So potentially use of SecureBoot > > > may already be impacted when using direct kernel boot. > > > > Yes, > > > > https://github.com/tianocore/edk2/commit/82808b422617 > > > > Ah yes, thanks for jogging my memory. > > So virt-install --network already ignores secure boot failures on > direct kernel boot, so this is not going to make it any worse.
And in a cloud world this isn't too much of a problem to start with. The cloud disks images will be built offline in trusted infrastructure, so lack of SecureBoot isn't a show stopper. When later deployed to the public cloud, SecureBoot (and/or Confidential Boot) will be fully operational, where it matters most. 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 :|
