tag 1015759 + confirmed
thanks
On Wed, Jul 20, 2022 at 04:45:03PM +0000, Robert wrote:
> Package: ovmf
> Version: 2022.05-2
> Severity: normal
> X-Debbugs-Cc: robert.schneide...@sap.com
>
> Dear Maintainer,
>
> I'm trying to test an image creation mechanism by booting the resulting
> image with QEMU with Secure Boot enforced. Unfortunately, the
> OVMF_VARS*.ms.fd seems to define a boot order where the EFI shell is
> placed before the disk.
Hm.. that must be a side effect of enrolling the keys, but I'm not
sure why that would be. Certainly we could clear the BootOrder
variable during that process, but I'd like to first understand what is
changing it to begin with.
> In other words, I land in an EFI shell when I try to boot. This only
> happens for the .ms.fd files; the OVMF_{CODE,VARS}_4M.fd directly boot
> the attached disk.
>
> I can change the boot order manually, save a new vars file and then boot
> from the disk using that vars file. However that was not quite easy for
> me to find out, I would appreciate if the secure-boot-enforcing and
> non-enforcing files could behave similarly with regards to the boot order.
>
> My qemu invocation:
>
> qemu-system-x86_64 \
> -machine q35 \
> -global ICH9-LPC.disable_s3=1 \
> -nodefaults \
> -nographic \
> -drive
> if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.ms.fd
> \
> -drive
> if=pflash,format=raw,unit=1,readonly=on,file=/usr/share/OVMF/OVMF_VARS_4M.ms.fd
> \
> -drive file=image.qcow2,media=disk,index=1 \
> -serial mon:stdio
>
> I'm not sure why the -machine and -global options are needed but I guess
> that's an unrelated issue.
Q35 is required for secure boot. The 4M images shouldn't need s3
disabled, but the 2M ones do (they use 64-bit PEI, which doesn't
support S3 w/ SMM).
