Re: [PATCH 10/10] start_vm: add support for secureboot

[Florian Bezdeka <florian.bezdeka@siemens.com>]

On Fri, 2023-01-27 at 08:11 +0000, Moessbauer, Felix wrote:
> On Fri, 2023-01-27 at 08:07 +0300, Uladzimir Bely wrote:
> > In mail from Friday, 23 December 2022 11:40:58 +03 user Felix
> > Moessbauer 
> > wrote:
> > > This patch adds a new -s parameter to enable the qemu secureboot
> > > support. To handle the persistency across reboots of the machine,
> > > we
> > > create a copy of the OVMF variables and pass that into qemu.
> > > 
> > > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > > ---
> > >  scripts/start_vm | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/scripts/start_vm b/scripts/start_vm
> > > index 3c0ba16..9cb7b9a 100755
> > > --- a/scripts/start_vm
> > > +++ b/scripts/start_vm
> > > @@ -51,6 +51,7 @@ show_help() {
> > >      echo "    -o, --out FILE        Route QEMU console output to"
> > >      echo "                          specified file."
> > >      echo "    -p, --pid FILE        Store QEMU pid to file."
> > > +    echo "    -s, --secureboot      Enable secureboot with default
> > > MS
> > > keys." echo "    --help                display this message and
> > > exit." echo
> > >      echo "Exit status:"
> > > @@ -93,6 +94,12 @@ do
> > >          EXTRA_ARGS="$EXTRA_ARGS -pidfile $2"
> > >          shift
> > >          ;;
> > > +    -s|--secureboot)
> > > +        OVMF_VARS_ORIG="/usr/share/OVMF/OVMF_VARS_4M.ms.fd"

WARNING: This path seems to be distribution specific. Does at least not
exist on my Fedora installation here.

$ find /usr -name "OVMF*"
/usr/share/OVMF
/usr/share/OVMF/OVMF_CODE.fd
/usr/share/OVMF/OVMF_CODE.secboot.fd
/usr/share/OVMF/OVMF_VARS.fd
/usr/share/OVMF/OVMF_VARS.secboot.fd
/usr/share/edk2/ovmf/OVMF.amdsev.fd
/usr/share/edk2/ovmf/OVMF.inteltdx.fd
/usr/share/edk2/ovmf/OVMF_CODE.cc.fd
/usr/share/edk2/ovmf/OVMF_CODE.fd
/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd
/usr/share/edk2/ovmf/OVMF_VARS.fd
/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd
/usr/share/edk2/ovmf-4m/OVMF_CODE.fd
/usr/share/edk2/ovmf-4m/OVMF_CODE.secboot.fd
/usr/share/edk2/ovmf-4m/OVMF_VARS.fd
/usr/share/edk2/ovmf-4m/OVMF_VARS.secboot.fd


> > > +        OVMF_VARS="$(basename "${OVMF_VARS_ORIG}")"
> > > +        cp "${OVMF_VARS_ORIG}" "${OVMF_VARS}"
> > 
> > Hi.
> > 
> > Since I'm working on some testsuite improvements, I made an attempt
> > to port 
> > this functionality (while it's already merged to 'next') from shell
> > `scripts/
> > start_vm` (that we plan to drop or just make a compatibility wrapper)
> > to 
> > python's `testsuite/start_vm.py`. But I faced the following problem:
> > 
> > cp: cannot stat '/usr/share/OVMF/OVMF_VARS_4M.ms.fd': No such file or
> > directory.
> > 
> > I have no such file neither on my any of my machines, nor on any
> > debian 
> > chroots I have, no in 'kas' docker images. It is not also mentioned
> > in the 
> > recipes. How does it work on your side? 
> 
> This is part of the ovmf package on debian (both the vars and the code
> / firmware). For secureboot, keys have to be deployed. As this series
> implements the debian sb chain, the efi shim is signed with the
> Microsoft keys, hence the `OVMF_VARS_4M.ms.fd` file is needed.
> 
> Further details can be found here: https://wiki.debian.org/SecureBoot
> 
> > 
> > Additionally, we definitely need a testcase for secureboot support.
> 
> Yes, that would be great. The question is just what to test. Doing a
> simple EFI + kernel boot test is trivial, but does not test the MOK
> integration and also not the signing of custom modules (modules have to
> be signed using a valid key so that the debian kernel is willing to
> load them when running under SB).
> 
> To test MOK, we have to boot, then enroll our MOK, reboot into the
> mokutil, inject our keys (e.g. via the passphrase workflow), then
> reboot into debian. And that cannot be done via SSH but needs local
> access to the terminal. Another option would be to enroll our keys
> directly into the OVMF_VARS, as it is done in cip-core SB.
> 
> All that is not trivial to implement.
> 
> Felix
> 
> > 
> > > +        EXTRA_ARGS="$EXTRA_ARGS -drive
> > > if=pflash,format=raw,unit=1,file=${OVMF_VARS}" +        ;;
> > >      *)
> > >          echo "error: invalid parameter '$key', please try '--help'
> > > to get
> > > list of supported parameters" exit $ES_BUG
> > 
> > 
> > 
> > 
>