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

["Moessbauer, Felix" <felix.moessbauer@siemens.com>]

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"
> > +        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
> 
> 
> 
>