Arch Linux

Looking at the Fedora build script I see that they enable 3 flags for the secureboot feature: SECURE_BOOT_ENABLE SMM_REQUIRE EXCLUDE_SHELL_FROM_FD. https://src.fedoraproject.org/rpms/edk2/blob/master/f/edk2.spec

Would EXCLUDE_SHELL_FROM_FD be useful for us as well?
It is great to clarify why SMM_REQUIRE does not work.

I did not really try hard to find out why SMM_REQUIRE didn't work for me.

It might be that I started qemu with parameters not compatible with the SMM feature. I found some more info here:
https://github.com/tianocore/edk2/blob/master/OvmfPkg/README

I will have to try it again and see if that works for me.

Hi Frank had you chance to digg into it?


I am looking at the instructions you mentioned (https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt) and it mentions following build parametes
-D SMM_REQUIRE -D SECURE_BOOT_ENABLE \
-D HTTP_BOOT_ENABLE -D TLS_ENABLE \

Haven't had a look again at this. Will give it a try in the next days.

I see similar boot issue with -DSMM_REQUIRE. With this flag I see the boot hangs and QEMU eats 3 cores. Removing SMM_REQUIRE allows to compile working secure boot firmware.

Alright, I pushed a new ovmf package to [testing]. It enables secure boot, TPM2, IP6. Please check if it matches your needs.

It would be great to resolve the issue with SSM_REQUIRE as well.

Thanks, I'll try it tomorrow.

The README (https://github.com/tianocore/edk2/blob/master/OvmfPkg/README) states a couple of things how to start qemu to get SMM to work with qemu.

I will also try it with SMM_REQUIRE again and following those instructions to see if it works then.

EDIT: typo

I tested ovmf form [testing] and secure boot works for me.

If you want you can close this now.

Hello,

I further investigated why that SMM_REQUIRE doesn't work. I got it to work now and attached a patch for the PKGBUILD [testing].

You will notice in the patch: "-a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc". I chose that config based on what is written here:

https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt#install-ovmf-from-source

QUOTE: We build the Ia32 (32-bit PEI and DXE) and Ia32X64 (32-bit PEI, 64-bit DXE) OVMF platforms because they support ACPI S3 suspend/resume and SMM at the same time. S3 is a demanding use case for the SMM infrastructure, therefore we should enable this combination.

QUOTE: The X64 build of OVMF does not support the same yet (UefiCpuPkg/Universal/Acpi/S3Resume2Pei forces OVMF to choose between S3 and SMM). Thankfully, the PEI bitness is entirely irrelevant to guest OSes, thus the Ia32X64 platform can be used identically, as far as OS-facing functionality is concerned.

So there's no harm using 32bit PEI/DXE on 64bit hosts (that's how I understand this).

If we build with "-a X64 -p OvmfPkg/OvmfPkgX64.dsc" then S3 suspend/resume has to be explicitly disabled on the qemu command line via "-global ICH9-LPC.disable_s3=1" otherwise qemu will hang.

Further, SMM_REQUIRE requires that qemu is started with the q35 machine type and other settings which are documented here: https://github.com/tianocore/edk2/blob/master/OvmfPkg/README

To summarize it, you have to start qemu like this:
-machine type=q35,smm=on,accel=kvm
-global driver=cfi.pflash01,property=secure,value=on
-global ICH9-LPC.disable_s3=0
-drive if=pflash,format=raw,unit=0,file=${ovmf_code},readonly
-drive if=pflash,format=raw,unit=1,file=${ovmf_vars}

ovmf_code would be set to /usr/share/ovmf/x64/OVMF_CODE.fd
and ovm_var would be set to a copy of /usr/share/ovmf/x64/OVMF_VARS.fd.

I'm not sure what release is targeted in the PKGBUILD. May I suggest we target the latest stable release, here's the announcement: https://lists.01.org/pipermail/edk2-devel/2018-August/028604.html

I also tried to compile with the newest openssl lib but it fails for me so I guess we have to go with what openssl-1.1.0h as it is right now.

I cleaned up PKBUILD further and attached it.

It uses the latest stable release as announced here:
https://lists.01.org/pipermail/edk2-devel/2018-August/028604.html

All options are activated, same as in the Fedora build.

I tested the build with qemu and secure boot works for me.

Fedora builds 2 flavors of ovmf firmware files - one 64bit without secure boot support, another is 64x32 with secure boot support (files OVMF_CODE.fd and OVMF_CODE.secboot.fd). Is it something we want to follow? Or should we just have one unified firmware with secboot support by default?

I think two flavors would be nice.

A build without SB (secure boot) is straightforward to use with qemu.

And a build with SB+SMM_REQUIRE would provide a full featured SB environment.

We could still opt for leaving out SMM_REQUIRE (due to the requirement it imposes on the qemu setup). However, now that we have confirmed it works with SMM_REQUIRE I'd include that.

Introducing a new secureboot firmware file is a bigger change that I am willing to do now. I'll probably wait until there will be need from our users for SMM feature.

For now I am going to release fw with secureboot but without SMM support. And SMM request should go to a separate bug if needed.

Frank, are you OK with it?

Sounds good to me.