Package: ovmf_2025.02-8+deb13u1_all.deb
Version: 2025.02-8
I downloaded your package to test secure boot and nx on QEMU. However, I
was surprised to see it allow me to load images that are only signed by the
embedded SHIM key.
1 - I used your OVMF_CODE_4M.secboot.strictnx.fd and OVMF_VARS_4M.ms.fd to
setup QEMU.
2 - My VMDK drive properly refused to boot my SHIM signed by my own DB key.
3 - I added my DB key to the db
4 - Booted properly to my application.
5 - My application used: EFI_STATUS status=gBS->LoadImage(FALSE, UEFI_IH,
filepath, filedata, filesize, &imagehandle); on another binary signed by
SHIM key (loaded in to aligned memory buffer).
6 - IT ALLOWED IT!!! It should be returning (status==EFI_SECURITY_VIOLATION
|| status==EFI_ACCESS_DENIED) like UEFI has been doing for a long time.
7 - I confirmed if I used EFI_SECURITY2_ARCH_PROTOCOL it will report the
error (I can't recall which of the two it reported).
8 - I also checked the secure boot variable, and it was 1.
So not sure what the heck is going on with these builds, but if that type of
logic is going to go mainstream, I'd need to know because I presume
gBS->LoadImage will properly check the secure boot database.
My batch file (yes I'm in Windows 11) looks like:
set varsfile=X:\OVMF\OVMF_VARS_4M.ms.fd
set codefile=X:\OVMF\OVMF_CODE_4M.secboot.fd
"C:\Program Files\qemu\qemu-system-x86_64.exe" ^
-machine q35 ^
-D ./qemu-debug-log ^
-m 4096 ^
-cpu max ^
-drive if=pflash,format=raw,readonly=on,file=%codefile% ^
-drive if=pflash,format=raw,file=%varsfile% ^
-drive
file=X:\virtualbox\Test-Multi-Boot\test-multi-boot.vmdk,format=vmdk,if=virti
o ^
-net none ^
-serial stdio
Regards,
--
David F.
TeraByte Unlimited
http://www.terabyteunlimited.com
