Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1015759: ovmf: OVMF_CODE_4M.ms.fd puts EFI shell first in boot order
175 views
Skip to first unread message
Robert
Jul 20, 2022, 12:50:04 PM7/20/22
to
Package: ovmf
Version: 2022.05-2
Severity: normal
X-Debbugs-Cc: robert.sc...@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.
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.
I've tested this in a container but I guess that shouldn't change the
behaviour.
Thank you very much for your maintenance of the OVMF package,
Robert
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.102.1-microsoft-standard-WSL2 (SMP w/16 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
-- no debconf information
Version: 2022.05-2
Severity: normal
X-Debbugs-Cc: robert.sc...@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.
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.
I've tested this in a container but I guess that shouldn't change the
behaviour.
Thank you very much for your maintenance of the OVMF package,
Robert
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.102.1-microsoft-standard-WSL2 (SMP w/16 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
-- no debconf information
dann frazier
Jul 21, 2022, 3:20:03 PM7/21/22
to
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.sc...@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).
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.sc...@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.
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.
disabled, but the 2M ones do (they use 64-bit PEI, which doesn't
support S3 w/ SMM).
Roland Clobus
Aug 10, 2022, 11:40:03 AM8/10/22
to
On 2022-08-07 the Wiki page was updated, independent of this ticket.
https://wiki.debian.org/SecureBoot/VirtualMachine#Change_the_boot_order
Today I added a link to this ticket in the Wiki page.
It would indeed be nice to have the boot order changed, because that
will enable openQA (https://openqa.debian.net) to run tests with UEFI
secure boot enabled. See also
https://salsa.debian.org/qa/openqa/openqa-tests-debian/-/merge_requests/3
With kind regards,
Roland Clobus
https://wiki.debian.org/SecureBoot/VirtualMachine#Change_the_boot_order
Today I added a link to this ticket in the Wiki page.
It would indeed be nice to have the boot order changed, because that
will enable openQA (https://openqa.debian.net) to run tests with UEFI
secure boot enabled. See also
https://salsa.debian.org/qa/openqa/openqa-tests-debian/-/merge_requests/3
With kind regards,
Roland Clobus
0 new messages