[PATCH 00/10] Add support for secureboot using Debian boot chain

[PATCH 00/10] Add support for secureboot using Debian boot chain

[Felix Moessbauer]

This series adds basic infrastructure to create ISAR images that
can be bootet on a stock amd64 machine with secureboot and MS keys.
Even if this comes with A LOT of limitations, we believe that this
is a very needed feature: More and more systems have Secureboot (SB)
enabled as default (MS keys enrolled) and often SB itself cannot be
turned off. Having support for that in ISAR makes it possible to
create two-staged images, where one image is used to configure the
SB (enroll keys, configure MOK) and then boot the actual target image.

Currently, in this situation a debian live image has to be used to
do the configuration (if the firmware graphical interface does not
support it).

When reviewing, please not the following:

- this series is in a very early state, but fully works in a QEMU
  as well as on some stock laptops
- it is AMD64 only and that will not change (Debian limitations)
- we need to make changes in the bootimg-efi-isar.py WIC plugin.
  These are additions only and are very debian specific, hence these
  should also remain ISAR only and not be proposed for OE
- the key handling topic (p6-8) is not mature from a conceptual
  perspective. Anyways, we do not want to spend too much time on it
  as this is just an example how key management could be done
- testing infrastructure is completely missing and that will not change
  soon, as we need to maintain a state across reboots of the qemu.
- These patches provide an easy way to create an image with any (signed)
  stock debian kernel that boots on most (all) SB enabled AMD64 machines.
  For that, no EFI config is required.

The series is structured as following:

p1-p3:  bare minimal support to boot with secureboot
p4,5:   module signing
p6-end: examples and helpers

Try it out:

Build it:
bitbake mc:qemuamd64-sb-bullseye:isar-image-base

Start it (consider adding -enable-kvm to get some decent performance):
start_vm -a amd64-sb -d bullseye -s

Check if SB is actually enabled (detected):
dmesg | grep secure
prints something like UEFI Secureboot is enabled

Try to load the example-module (it should fail):
modprobe example-module

Enroll our MOK and reboot:
mokutil --import /etc/sb-mok-keys/MOK/MOK.der

Now, use the previously definded password to enroll the key, then reboot.

Now our image should be up again and modprobe example-module should work.

Best regards,
Felix
Siemens AG

Felix Moessbauer (10):
  wic: add option to use debian EFI shim
  add debian sb chain bootloader dependencies
  add example wic file for sb debian boot chain
  style: split overlong line in module.inc
  add support to sign kernel modules
  add example to generated and distribute MOK data
  add signed variant of example-module
  add new machine qemuamd64-sb and corresponding mc
  fix: only append kargs and extra_kargs if set
  start_vm: add support for secureboot

 meta-isar/conf/local.conf.sample              |  1 +
 meta-isar/conf/machine/qemuamd64-sb.conf      | 20 ++++++++++++++
 .../multiconfig/qemuamd64-sb-bullseye.conf    | 12 +++++++++
 .../example-module/example-module-signed.bb   | 14 ++++++++++
 .../sb-mok-keys/files/Makefile.tmpl           | 27 +++++++++++++++++++
 .../sb-mok-keys/sb-mok-keys.bb                | 23 ++++++++++++++++
 .../sb-mok-public/files/rules                 | 12 +++++++++
 .../sb-mok-public/sb-mok-public.bb            | 17 ++++++++++++
 .../wic/canned-wks/sdimage-efi-sb-debian.wks  | 10 +++++++
 meta/conf/distro/debian-common.conf           |  3 +++
 .../linux-module/files/debian/rules.tmpl      |  3 +++
 meta/recipes-kernel/linux-module/module.inc   | 15 ++++++++++-
 .../wic/plugins/source/bootimg-efi-isar.py    | 16 +++++++++++
 scripts/start_vm                              | 10 ++++++-
 14 files changed, 181 insertions(+), 2 deletions(-)
 create mode 100644 meta-isar/conf/machine/qemuamd64-sb.conf
 create mode 100644 meta-isar/conf/multiconfig/qemuamd64-sb-bullseye.conf
 create mode 100644 meta-isar/recipes-kernel/example-module/example-module-signed.bb
 create mode 100644 meta-isar/recipes-secureboot/sb-mok-keys/files/Makefile.tmpl
 create mode 100644 meta-isar/recipes-secureboot/sb-mok-keys/sb-mok-keys.bb
 create mode 100644 meta-isar/recipes-secureboot/sb-mok-public/files/rules
 create mode 100644 meta-isar/recipes-secureboot/sb-mok-public/sb-mok-public.bb
 create mode 100644 meta-isar/scripts/lib/wic/canned-wks/sdimage-efi-sb-debian.wks

-- 
2.34.1

[PATCH 01/10] wic: add option to use debian EFI shim

[Felix Moessbauer]

This patch extends the bootimg-efi-isar WIC plugin by adding support for
the debian SB boot chain. This is controlled by the source-params option
use-debian-sb-stub. When set to true, the EFI shim signed by Microsoft
is used as first-stage bootloader. This then loads the grubx64.efi
loader which is signed by the Debian UEFI CA. This loader then loads an
official debian kernel, also signed by Debian.

By that, no changes to the chain are possible and it can only be used to
boot stock debian kernels. Given these limitations, this pattern is very
useful to boot these images on systems where secure boot is enabled and
default (MS) keys are enrolled.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 .../lib/wic/plugins/source/bootimg-efi-isar.py   | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py
index 006c8bc..139ef46 100644
--- a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py
+++ b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py
@@ -303,6 +303,10 @@ class BootimgEFIPlugin(SourcePlugin):
             if not kernel_dir:
                 raise WicError("Couldn't find DEPLOY_DIR_IMAGE, exiting")
 
+        if source_params.get('use-debian-sb-stub') == "true":
+            if get_bitbake_var("DISTRO_ARCH") != "amd64" or source_params['loader'] != 'grub-efi':
+                raise WicError("use-debian-sb-stub only supported in grub-efi on amd64")
+
         staging_kernel_dir = kernel_dir
 
         hdddir = "%s/hdd/boot" % cr_workdir
@@ -435,6 +439,18 @@ class BootimgEFIPlugin(SourcePlugin):
                     grub_cmd += "memdisk ls search_fs_uuid udf btrfs xfs lvm "
                     grub_cmd += "reiserfs regexp " + grub_modules
                     exec_cmd(grub_cmd)
+
+                if source_params.get('use-debian-sb-stub') == "true":
+                    files = [
+                        # src, efiname, mandatory
+                        ("/usr/lib/shim/shimx64.efi.signed", "bootx64.efi", True),
+                        ("/usr/lib/shim/mmx64.efi.signed", "mmx64.efi", False),
+                        ("/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed", "grubx64.efi", True)
+                    ]
+                    for s,e,m in files:
+                        cp_cmd = "cp %s %s/EFI/BOOT/%s" % (s, bootimg_dir, e)
+                        exec_cmd(cp_cmd, m)
+
             elif source_params['loader'] == 'systemd-boot':
                 # backup kernel dir before overwriting
                 kernel_dir_orig = kernel_dir
-- 
2.34.1

[PATCH 02/10] add debian sb chain bootloader dependencies

[Felix Moessbauer]

This patch adds a new entry GRUB_DEBIAN_SB_CHAIN to debian-common.conf
which provides the imager dependencies for the secure boot debian efi
bootloader chain.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta/conf/distro/debian-common.conf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/conf/distro/debian-common.conf b/meta/conf/distro/debian-common.conf
index ada7dc6..5139c7d 100644
--- a/meta/conf/distro/debian-common.conf
+++ b/meta/conf/distro/debian-common.conf
@@ -28,6 +28,9 @@ GRUB_BOOTLOADER_INSTALL_i386 = "grub-efi-ia32-bin"
 GRUB_BOOTLOADER_INSTALL_armhf = "grub-efi-arm-bin"
 GRUB_BOOTLOADER_INSTALL_arm64 = "grub-efi-arm64-bin"
 
+GRUB_DEBIAN_SB_CHAIN_amd64 = "grub-efi-amd64-signed shim-signed"
+GRUB_DEBIAN_SB_MOK_amd64 = "shim-helpers-amd64-signed"
+
 SYSLINUX_BOOTLOADER_INSTALL = "syslinux syslinux-common"
 
 SYSTEMD_BOOTLOADER_INSTALL = "systemd:${DISTRO_ARCH}"
-- 
2.34.1

[PATCH 03/10] add example wic file for sb debian boot chain

[Felix Moessbauer]

This patch adds an example WKS file to show how to use the secure boot
debian boot chain.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 .../lib/wic/canned-wks/sdimage-efi-sb-debian.wks       | 10 ++++++++++
 1 file changed, 10 insertions(+)
 create mode 100644 meta-isar/scripts/lib/wic/canned-wks/sdimage-efi-sb-debian.wks

diff --git a/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi-sb-debian.wks b/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi-sb-debian.wks
new file mode 100644
index 0000000..cd99ebc
--- /dev/null
+++ b/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi-sb-debian.wks
@@ -0,0 +1,10 @@
+# short-description: Create an EFI disk image using the debian secure boot chain
+# long-description: Creates a partitioned EFI disk image without any swap that
+# can be bootet on any UEFI with secure boot enabled and MS keys enrolled.
+# Note, that this only works with grub and on amd64
+
+part /boot --source bootimg-efi-isar --sourceparams "loader=grub-efi,use-debian-sb-stub=true" --ondisk sda --label efi --part-type EF00 --align 1024
+
+part / --source rootfs --ondisk sda --fstype ext4 --mkfs-extraopts "-T default" --label platform --align 1024 --use-uuid --exclude-path boot/
+
+bootloader --ptable gpt --timeout 3 --append "rootwait console=ttyS0,115200 console=tty0"
-- 
2.34.1

[PATCH 04/10] style: split overlong line in module.inc

[Felix Moessbauer]

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta/recipes-kernel/linux-module/module.inc | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-module/module.inc b/meta/recipes-kernel/linux-module/module.inc
index b04f5f1..cfc6d20 100644
--- a/meta/recipes-kernel/linux-module/module.inc
+++ b/meta/recipes-kernel/linux-module/module.inc
@@ -27,7 +27,13 @@ inherit dpkg
 TEMPLATE_FILES = "debian/control.tmpl \
                   debian/changelog.tmpl \
                   debian/rules.tmpl"
-TEMPLATE_VARS += "KERNEL_NAME KERNEL_TYPE KERNEL_IMAGE_PKG KERNEL_HEADERS_PKG DEBIAN_BUILD_DEPENDS PN"
+TEMPLATE_VARS += " \
+    KERNEL_NAME \
+    KERNEL_TYPE \
+    KERNEL_IMAGE_PKG \
+    KERNEL_HEADERS_PKG \
+    DEBIAN_BUILD_DEPENDS \
+    PN"
 
 do_prepare_build() {
     rm -rf ${S}/debian
-- 
2.34.1

[PATCH 05/10] add support to sign kernel modules

[Felix Moessbauer]

This patchs extends the module.inc class to add support to sign the
compiled kernel modules. If the module is signed or not is controlled
via a build profile named pkg.sign. When enabled, the kernels sign-file
is executed. The path to the keyfile inside the schroot has to be
provided in SIGNATURE_KEYFILE, the path to the corresponding cert in
SIGNATURE_CERTFILE. The used hash-function can be controlled using
SIGNATURE_HASHFN. All modules in the current build directory are
signed.

The implementation - by design - does not specify how to provide the
keys in the schroot inside the sbuild. This gives some flexibility, e.g.
the keys can be provided in a package, added as build dependency or
alternatively via a mountpoint.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta/recipes-kernel/linux-module/files/debian/rules.tmpl | 3 +++
 meta/recipes-kernel/linux-module/module.inc              | 7 +++++++
 2 files changed, 10 insertions(+)

diff --git a/meta/recipes-kernel/linux-module/files/debian/rules.tmpl b/meta/recipes-kernel/linux-module/files/debian/rules.tmpl
index c1c2560..7d950e3 100755
--- a/meta/recipes-kernel/linux-module/files/debian/rules.tmpl
+++ b/meta/recipes-kernel/linux-module/files/debian/rules.tmpl
@@ -50,6 +50,9 @@ override_dh_auto_clean:
 
 override_dh_auto_build:
 	$(MAKE) -C $(KDIR) M=$(PWD) $(PARALLEL_MAKE) modules
+ifneq ($(filter pkg.sign,$(DEB_BUILD_PROFILES)),)
+	find . -name "*.ko" -print -exec $(KDIR)/scripts/sign-file ${SIGNATURE_HASHFN} ${SIGNATURE_KEYFILE} ${SIGNATURE_CERTFILE} {} \;
+endif
 
 override_dh_auto_install:
 	$(MAKE) -C $(KDIR) M=$(PWD) INSTALL_MOD_PATH=$(PWD)/debian/${PN} modules_install
diff --git a/meta/recipes-kernel/linux-module/module.inc b/meta/recipes-kernel/linux-module/module.inc
index cfc6d20..a9e5d3d 100644
--- a/meta/recipes-kernel/linux-module/module.inc
+++ b/meta/recipes-kernel/linux-module/module.inc
@@ -18,6 +18,10 @@ KERNEL_HEADERS_PKG ??= "linux-headers-${KERNEL_NAME}"
 DEPENDS += "${KERNEL_HEADERS_PKG}"
 DEBIAN_BUILD_DEPENDS = "${KERNEL_HEADERS_PKG}"
 
+SIGNATURE_KEYFILE ??= ""
+SIGNATURE_CERTFILE ??= ""
+SIGNATURE_HASHFN ??= "sha256"
+
 SRC_URI += "file://debian/"
 
 AUTOLOAD ?= ""
@@ -33,6 +37,9 @@ TEMPLATE_VARS += " \
     KERNEL_IMAGE_PKG \
     KERNEL_HEADERS_PKG \
     DEBIAN_BUILD_DEPENDS \
+    SIGNATURE_KEYFILE \
+    SIGNATURE_CERTFILE \
+    SIGNATURE_HASHFN \
     PN"
 
 do_prepare_build() {
-- 
2.34.1

[PATCH 06/10] add example to generated and distribute MOK data

[Felix Moessbauer]

This patch adds two recipes to easily handle a Machine Owner Key (MOK)
that can be used to sign kernel modules or other components.

The sb-mok-keys package generates a x509 certificate at build time and
adds both the certificate and the private key to a binary package.
This is implemented in a way that the source package does not contain
any keys, but only the binary package does. While this breaks
reproducability, this ensures that the keys never end up in a src
repository.

A second package sb-mok-public is provided to distribute the generated
key into the target image (to inject into EFI at runtime). This package
build-depends on the sb-mok-keys, but conflicts at runtime to make sure
that the private key cannot be installed into the target image (given
that the -public package is installed).

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 .../sb-mok-keys/files/Makefile.tmpl           | 27 +++++++++++++++++++
 .../sb-mok-keys/sb-mok-keys.bb                | 23 ++++++++++++++++
 .../sb-mok-public/files/rules                 | 12 +++++++++
 .../sb-mok-public/sb-mok-public.bb            | 17 ++++++++++++
 4 files changed, 79 insertions(+)
 create mode 100644 meta-isar/recipes-secureboot/sb-mok-keys/files/Makefile.tmpl
 create mode 100644 meta-isar/recipes-secureboot/sb-mok-keys/sb-mok-keys.bb
 create mode 100644 meta-isar/recipes-secureboot/sb-mok-public/files/rules
 create mode 100644 meta-isar/recipes-secureboot/sb-mok-public/sb-mok-public.bb

diff --git a/meta-isar/recipes-secureboot/sb-mok-keys/files/Makefile.tmpl b/meta-isar/recipes-secureboot/sb-mok-keys/files/Makefile.tmpl
new file mode 100644
index 0000000..b377c51
--- /dev/null
+++ b/meta-isar/recipes-secureboot/sb-mok-keys/files/Makefile.tmpl
@@ -0,0 +1,27 @@
+# Base image recipe for ISAR
+#
+# This software is a part of ISAR.
+# Copyright (C) 2022 Siemens AG
+
+CN=${COMMON_NAME}
+
+all: create_key
+
+create_key:
+	mkdir MOK
+	openssl req -new -x509 -newkey rsa:2048 -keyout MOK/MOK.priv -outform DER -out MOK/MOK.der -nodes -days 36500 -subj "/CN=$(CN)/"
+	chmod 600 MOK/MOK.priv
+
+install:
+	install -d $(DESTDIR)/etc/sb-mok-keys/MOK
+	# note that this will later be changed by dh_fixperms
+	# this is also required so that the non-privileged sbuild
+	# user can read the file
+	install -m 644 MOK/MOK.priv $(DESTDIR)/etc/sb-mok-keys/MOK/
+	install -m 644 MOK/MOK.der  $(DESTDIR)/etc/sb-mok-keys/MOK/
+
+clean:
+ifneq (,$(wildcard ./MOK/MOK.priv))
+	shred MOK/MOK.priv
+endif
+	rm -rf MOK
diff --git a/meta-isar/recipes-secureboot/sb-mok-keys/sb-mok-keys.bb b/meta-isar/recipes-secureboot/sb-mok-keys/sb-mok-keys.bb
new file mode 100644
index 0000000..6137834
--- /dev/null
+++ b/meta-isar/recipes-secureboot/sb-mok-keys/sb-mok-keys.bb
@@ -0,0 +1,23 @@
+# Base image recipe for ISAR
+#
+# This software is a part of ISAR.
+# Copyright (C) 2022 Siemens AG
+
+inherit dpkg
+
+
+SRC_URI = "file://Makefile.tmpl"
+S = "${WORKDIR}/src"
+
+TEMPLATE_VARS = "COMMON_NAME"
+TEMPLATE_FILES = "Makefile.tmpl"
+
+DEBIAN_BUILD_DEPENDS .= ",openssl"
+# common name of x509 certificate used for signing
+COMMON_NAME = "ISAR Builder"
+
+do_prepare_build[cleandirs] += "${S}/debian"
+do_prepare_build() {
+    cp ${WORKDIR}/Makefile ${S}
+    deb_debianize
+}
diff --git a/meta-isar/recipes-secureboot/sb-mok-public/files/rules b/meta-isar/recipes-secureboot/sb-mok-public/files/rules
new file mode 100644
index 0000000..305b443
--- /dev/null
+++ b/meta-isar/recipes-secureboot/sb-mok-public/files/rules
@@ -0,0 +1,12 @@
+#!/usr/bin/make -f
+# Base image recipe for ISAR
+#
+# This software is a part of ISAR.
+# Copyright (C) 2022 Siemens AG
+
+%:
+	dh $@
+
+override_dh_install:
+	install -d debian/sb-mok-public/etc/sb-mok-keys/MOK/
+	install -m 644 /etc/sb-mok-keys/MOK/MOK.der debian/sb-mok-public/etc/sb-mok-keys/MOK/MOK.der
diff --git a/meta-isar/recipes-secureboot/sb-mok-public/sb-mok-public.bb b/meta-isar/recipes-secureboot/sb-mok-public/sb-mok-public.bb
new file mode 100644
index 0000000..46fdeed
--- /dev/null
+++ b/meta-isar/recipes-secureboot/sb-mok-public/sb-mok-public.bb
@@ -0,0 +1,17 @@
+# Base image recipe for ISAR
+#
+# This software is a part of ISAR.
+# Copyright (C) 2022 Siemens AG
+
+inherit dpkg
+
+DEPENDS += "sb-mok-keys"
+DEBIAN_BUILD_DEPENDS .= ",sb-mok-keys"
+DEBIAN_CONFLICTS .= ",sb-mok-keys"
+
+SRC_URI = "file://rules"
+
+do_prepare_build[cleandirs] += "${S}/debian"
+do_prepare_build() {
+    deb_debianize
+}
-- 
2.34.1

[PATCH 07/10] add signed variant of example-module

[Felix Moessbauer]

This patch adds an example how to use the sb-mok-* recipes to create a
signed out-of-tree kernel module.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 .../example-module/example-module-signed.bb        | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 meta-isar/recipes-kernel/example-module/example-module-signed.bb

diff --git a/meta-isar/recipes-kernel/example-module/example-module-signed.bb b/meta-isar/recipes-kernel/example-module/example-module-signed.bb
new file mode 100644
index 0000000..45f114b
--- /dev/null
+++ b/meta-isar/recipes-kernel/example-module/example-module-signed.bb
@@ -0,0 +1,14 @@
+# Example recipe for building a custom module
+#
+# This software is a part of ISAR.
+# Copyright (c) Siemens AG, 2022
+#
+# SPDX-License-Identifier: MIT
+
+require example-module.bb
+
+DEPENDS += "sb-mok-keys"
+DEBIAN_BUILD_DEPENDS .= ', sb-mok-keys'
+DEB_BUILD_PROFILES += 'pkg.sign'
+SIGNATURE_KEYFILE  = '/etc/sb-mok-keys/MOK/MOK.priv'
+SIGNATURE_CERTFILE = '/etc/sb-mok-keys/MOK/MOK.der'
-- 
2.34.1

[PATCH 08/10] add new machine qemuamd64-sb and corresponding mc

[Felix Moessbauer]

The newly added machine qemuamd64-sb provides a bare minimal config to
boot an ISAR image on a stock amd64 system with secureboot enabled and
default MS keys renrolled. To make that work, we use the stock debian
bootloader chain, which is the debian-shim (signed by MS) that loads
grub (signed by Debian) that loads a vanilla debian kernel (signed by
debian). By that, this configuration will only work with official debian
kernels for the inital boot. Once this is bootet, we can use the running
system to modify the MOK and / or control the signatures that are
allowed to be loaded by the firmware.

The qemuamd64-sb-bullseye multiconfig extends that pattern and adds
support to modify the MOK. For that, we add the mok shim helper (.efi)
and the mokutil userspace tool to modify the MOK.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta-isar/conf/local.conf.sample              |  1 +
 meta-isar/conf/machine/qemuamd64-sb.conf      | 20 +++++++++++++++++++
 .../multiconfig/qemuamd64-sb-bullseye.conf    | 12 +++++++++++
 3 files changed, 33 insertions(+)
 create mode 100644 meta-isar/conf/machine/qemuamd64-sb.conf
 create mode 100644 meta-isar/conf/multiconfig/qemuamd64-sb-bullseye.conf

diff --git a/meta-isar/conf/local.conf.sample b/meta-isar/conf/local.conf.sample
index 57d0620..77b3a32 100644
--- a/meta-isar/conf/local.conf.sample
+++ b/meta-isar/conf/local.conf.sample
@@ -53,6 +53,7 @@ BBMULTICONFIG = " \
     qemuamd64-stretch \
     qemuamd64-buster \
     qemuamd64-bullseye \
+    qemuamd64-sb-bullseye \
     qemuamd64-bookworm \
     container-amd64-stretch \
     container-amd64-buster \
diff --git a/meta-isar/conf/machine/qemuamd64-sb.conf b/meta-isar/conf/machine/qemuamd64-sb.conf
new file mode 100644
index 0000000..c581ab3
--- /dev/null
+++ b/meta-isar/conf/machine/qemuamd64-sb.conf
@@ -0,0 +1,20 @@
+# This software is a part of ISAR.
+# Copyright (C) 2022 Siemens AG
+
+DISTRO_ARCH ?= "amd64"
+
+KERNEL_NAME ?= "amd64"
+
+IMAGE_FSTYPES ?= "wic"
+WKS_FILE ?= "sdimage-efi-sb-debian"
+IMAGER_INSTALL += "${GRUB_DEBIAN_SB_CHAIN}"
+
+IMAGE_INSTALL += "sshd-regen-keys"
+
+QEMU_ARCH ?= "x86_64"
+QEMU_MACHINE ?= "q35"
+QEMU_CPU ?= ""
+QEMU_DISK_ARGS ?= "-drive file=##ROOTFS_IMAGE##,format=raw -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=/usr/share/OVMF/OVMF_CODE_4M.ms.fd,readonly=on"
+
+MACHINE_SERIAL ?= "ttyS0"
+BAUDRATE_TTY ?= "115200"
diff --git a/meta-isar/conf/multiconfig/qemuamd64-sb-bullseye.conf b/meta-isar/conf/multiconfig/qemuamd64-sb-bullseye.conf
new file mode 100644
index 0000000..19a105e
--- /dev/null
+++ b/meta-isar/conf/multiconfig/qemuamd64-sb-bullseye.conf
@@ -0,0 +1,12 @@
+# This software is a part of ISAR.
+MACHINE ?= "qemuamd64-sb"
+DISTRO ?= "debian-bullseye"
+
+# include public keys
+IMAGE_INSTALL += "sb-mok-public"
+# include signed example module
+IMAGE_INSTALL += "example-module-signed-${KERNEL_NAME}"
+
+# add MOK utilities to insert MOK into EFI
+IMAGER_INSTALL += "${GRUB_DEBIAN_SB_MOK}"
+IMAGE_PREINSTALL += "mokutil"
-- 
2.34.1

[PATCH 09/10] fix: only append kargs and extra_kargs if set

[Felix Moessbauer]

This fixes an issue when no KARGS and no EXTRA_KARGS where set, leading
to an empty string after -append. This happens for instance when booting
a WIC image instead of performing a direct kernel boot.

Instead of always adding -append, we only add it if at least on of the
variables is set.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 scripts/start_vm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/start_vm b/scripts/start_vm
index 8876e53..3c0ba16 100755
--- a/scripts/start_vm
+++ b/scripts/start_vm
@@ -19,6 +19,7 @@ bb2sh() {
 start_qemu() {
     root=`echo $QEMU_DISK_ARGS \
         | sed 's,##ROOTFS_IMAGE##,'$IMAGE_DIR/$ROOTFS_IMAGE','`
+    [ -n "$KARGS$EXTRA_KARGS" ] && OPT_KERNEL_ARGS="-append $KARGS$EXTRA_KARGS"
     local had_x
     echo $- | grep -q x && had_x=1 || had_x=0
     [ $had_x -eq 0 ] && set -x
@@ -28,7 +29,7 @@ start_qemu() {
 	$QCPU \
 	-nographic \
 	$EXTRA_ARGS \
-        -append "$KARGS$EXTRA_KARGS" \
+    $OPT_KERNEL_ARGS \
 	$root
     [ $had_x -eq 0 ] && set +x
 }
-- 
2.34.1

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

[Felix Moessbauer]

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

Re: [PATCH 00/10] Add support for secureboot using Debian boot chain

[Uladzimir Bely]

In mail from пятница, 23 декабря 2022 г. 11:40:48 +03 user Felix Moessbauer 
wrote:
> This series adds basic infrastructure to create ISAR images that
> can be bootet on a stock amd64 machine with secureboot and MS keys.
> Even if this comes with A LOT of limitations, we believe that this
> is a very needed feature: More and more systems have Secureboot (SB)
> enabled as default (MS keys enrolled) and often SB itself cannot be
> turned off. Having support for that in ISAR makes it possible to
> create two-staged images, where one image is used to configure the
> SB (enroll keys, configure MOK) and then boot the actual target image.
> 
> Currently, in this situation a debian live image has to be used to
> do the configuration (if the firmware graphical interface does not
> support it).
> 
> When reviewing, please not the following:
> 
> - this series is in a very early state, but fully works in a QEMU
>   as well as on some stock laptops
> - it is AMD64 only and that will not change (Debian limitations)
> - we need to make changes in the bootimg-efi-isar.py WIC plugin.
>   These are additions only and are very debian specific, hence these
>   should also remain ISAR only and not be proposed for OE
> - the key handling topic (p6-8) is not mature from a conceptual
>   perspective. Anyways, we do not want to spend too much time on it
>   as this is just an example how key management could be done
> - testing infrastructure is completely missing and that will not change
>   soon, as we need to maintain a state across reboots of the qemu.
> - These patches provide an easy way to create an image with any (signed)
>   stock debian kernel that boots on most (all) SB enabled AMD64 machines.
>   For that, no EFI config is required.
> 
> The series is structured as following:
> 
> p1-p3:  bare minimal support to boot with secureboot
> p4,5:   module signing
> p6-end: examples and helpers
> 
> Try it out:
> 
> Build it:
> bitbake mc:qemuamd64-sb-bullseye:isar-image-base
> 
> Start it (consider adding -enable-kvm to get some decent performance):
> start_vm -a amd64-sb -d bullseye -s
> 
> Check if SB is actually enabled (detected):
> dmesg | grep secure
> prints something like UEFI Secureboot is enabled
> 
> Try to load the example-module (it should fail):
> modprobe example-module
> 
> Enroll our MOK and reboot:
> mokutil --import /etc/sb-mok-keys/MOK/MOK.der
> 
> Now, use the previously definded password to enroll the key, then reboot.
> 
> Now our image should be up again and modprobe example-module should work.
> 
> Best regards,
> Felix
> Siemens AG
> 
> Felix Moessbauer (10):
>   wic: add option to use debian EFI shim
>   add debian sb chain bootloader dependencies
>   add example wic file for sb debian boot chain
>   style: split overlong line in module.inc
>   add support to sign kernel modules
>   add example to generated and distribute MOK data
>   add signed variant of example-module
>   add new machine qemuamd64-sb and corresponding mc
>   fix: only append kargs and extra_kargs if set
>   start_vm: add support for secureboot
> 
>  meta-isar/conf/local.conf.sample              |  1 +
>  meta-isar/conf/machine/qemuamd64-sb.conf      | 20 ++++++++++++++
>  .../multiconfig/qemuamd64-sb-bullseye.conf    | 12 +++++++++
>  .../example-module/example-module-signed.bb   | 14 ++++++++++
>  .../sb-mok-keys/files/Makefile.tmpl           | 27 +++++++++++++++++++
>  .../sb-mok-keys/sb-mok-keys.bb                | 23 ++++++++++++++++
>  .../sb-mok-public/files/rules                 | 12 +++++++++
>  .../sb-mok-public/sb-mok-public.bb            | 17 ++++++++++++
>  .../wic/canned-wks/sdimage-efi-sb-debian.wks  | 10 +++++++
>  meta/conf/distro/debian-common.conf           |  3 +++
>  .../linux-module/files/debian/rules.tmpl      |  3 +++
>  meta/recipes-kernel/linux-module/module.inc   | 15 ++++++++++-
>  .../wic/plugins/source/bootimg-efi-isar.py    | 16 +++++++++++
>  scripts/start_vm                              | 10 ++++++-
>  14 files changed, 181 insertions(+), 2 deletions(-)
>  create mode 100644 meta-isar/conf/machine/qemuamd64-sb.conf
>  create mode 100644 meta-isar/conf/multiconfig/qemuamd64-sb-bullseye.conf
>  create mode 100644
> meta-isar/recipes-kernel/example-module/example-module-signed.bb create
> mode 100644 meta-isar/recipes-secureboot/sb-mok-keys/files/Makefile.tmpl
> create mode 100644 meta-isar/recipes-secureboot/sb-mok-keys/sb-mok-keys.bb
> create mode 100644 meta-isar/recipes-secureboot/sb-mok-public/files/rules
> create mode 100644
> meta-isar/recipes-secureboot/sb-mok-public/sb-mok-public.bb create mode
> 100644 meta-isar/scripts/lib/wic/canned-wks/sdimage-efi-sb-debian.wks

Applied to next, thanks.

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

[Uladzimir Bely]

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? 

Additionally, we definitely need a testcase for secureboot support.

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

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

[Moessbauer, Felix]

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

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

[Florian Bezdeka]

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

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

[Uladzimir Bely]

In mail from Friday, 27 January 2023 11:41:53 +03 user Florian Bezdeka wrote:
> 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.

Yes, that's why I was a bit confused. I didn't see it in my Gentoo system, 
didn't find it in buster (which we still use for CI). Kas image (bullseye-
based) also don't include it, but it's at least installable.

> 
> $ 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

Re: [PATCH 06/10] add example to generated and distribute MOK data

[Jan Kiszka]

On 23.12.22 09:40, Felix Moessbauer wrote:
> This patch adds two recipes to easily handle a Machine Owner Key (MOK)
> that can be used to sign kernel modules or other components.
> 
> The sb-mok-keys package generates a x509 certificate at build time and
> adds both the certificate and the private key to a binary package.
> This is implemented in a way that the source package does not contain
> any keys, but only the binary package does. While this breaks
> reproducability, this ensures that the keys never end up in a src
> repository.

It's still not usable in case of externally managed keys (security
tokens, trust centers etc.). This should be made clear, and we still
need to invent a pattern for such cases which are more common in production.

Jan

> 
> A second package sb-mok-public is provided to distribute the generated
> key into the target image (to inject into EFI at runtime). This package
> build-depends on the sb-mok-keys, but conflicts at runtime to make sure
> that the private key cannot be installed into the target image (given
> that the -public package is installed).
> 
> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> ---
>  .../sb-mok-keys/files/Makefile.tmpl           | 27 +++++++++++++++++++
>  .../sb-mok-keys/sb-mok-keys.bb                | 23 ++++++++++++++++
>  .../sb-mok-public/files/rules                 | 12 +++++++++
>  .../sb-mok-public/sb-mok-public.bb            | 17 ++++++++++++
>  4 files changed, 79 insertions(+)
>  create mode 100644 meta-isar/recipes-secureboot/sb-mok-keys/files/Makefile.tmpl
>  create mode 100644 meta-isar/recipes-secureboot/sb-mok-keys/sb-mok-keys.bb
>  create mode 100644 meta-isar/recipes-secureboot/sb-mok-public/files/rules
>  create mode 100644 meta-isar/recipes-secureboot/sb-mok-public/sb-mok-public.bb
> 
> diff --git a/meta-isar/recipes-secureboot/sb-mok-keys/files/Makefile.tmpl b/meta-isar/recipes-secureboot/sb-mok-keys/files/Makefile.tmpl
> new file mode 100644
> index 0000000..b377c51
> --- /dev/null
> +++ b/meta-isar/recipes-secureboot/sb-mok-keys/files/Makefile.tmpl
> @@ -0,0 +1,27 @@
> +# Base image recipe for ISAR
> +#
> +# This software is a part of ISAR.
> +# Copyright (C) 2022 Siemens AG
> +
> +CN=${COMMON_NAME}
> +
> +all: create_key
> +
> +create_key:
> +	mkdir MOK
> +	openssl req -new -x509 -newkey rsa:2048 -keyout MOK/MOK.priv -outform DER -out MOK/MOK.der -nodes -days 36500 -subj "/CN=$(CN)/"
> +	chmod 600 MOK/MOK.priv
> +
> +install:
> +	install -d $(DESTDIR)/etc/sb-mok-keys/MOK
> +	# note that this will later be changed by dh_fixperms
> +	# this is also required so that the non-privileged sbuild
> +	# user can read the file
> +	install -m 644 MOK/MOK.priv $(DESTDIR)/etc/sb-mok-keys/MOK/
> +	install -m 644 MOK/MOK.der  $(DESTDIR)/etc/sb-mok-keys/MOK/
> +
> +clean:
> +ifneq (,$(wildcard ./MOK/MOK.priv))
> +	shred MOK/MOK.priv
> +endif
> +	rm -rf MOK
> diff --git a/meta-isar/recipes-secureboot/sb-mok-keys/sb-mok-keys.bb b/meta-isar/recipes-secureboot/sb-mok-keys/sb-mok-keys.bb
> new file mode 100644
> index 0000000..6137834
> --- /dev/null
> +++ b/meta-isar/recipes-secureboot/sb-mok-keys/sb-mok-keys.bb
> @@ -0,0 +1,23 @@
> +# Base image recipe for ISAR
> +#
> +# This software is a part of ISAR.
> +# Copyright (C) 2022 Siemens AG
> +
> +inherit dpkg
> +
> +
> +SRC_URI = "file://Makefile.tmpl"
> +S = "${WORKDIR}/src"
> +
> +TEMPLATE_VARS = "COMMON_NAME"
> +TEMPLATE_FILES = "Makefile.tmpl"
> +
> +DEBIAN_BUILD_DEPENDS .= ",openssl"
> +# common name of x509 certificate used for signing
> +COMMON_NAME = "ISAR Builder"
> +
> +do_prepare_build[cleandirs] += "${S}/debian"
> +do_prepare_build() {
> +    cp ${WORKDIR}/Makefile ${S}
> +    deb_debianize
> +}
> diff --git a/meta-isar/recipes-secureboot/sb-mok-public/files/rules b/meta-isar/recipes-secureboot/sb-mok-public/files/rules
> new file mode 100644
> index 0000000..305b443
> --- /dev/null
> +++ b/meta-isar/recipes-secureboot/sb-mok-public/files/rules
> @@ -0,0 +1,12 @@
> +#!/usr/bin/make -f
> +# Base image recipe for ISAR
> +#
> +# This software is a part of ISAR.
> +# Copyright (C) 2022 Siemens AG
> +
> +%:
> +	dh $@
> +
> +override_dh_install:
> +	install -d debian/sb-mok-public/etc/sb-mok-keys/MOK/
> +	install -m 644 /etc/sb-mok-keys/MOK/MOK.der debian/sb-mok-public/etc/sb-mok-keys/MOK/MOK.der
> diff --git a/meta-isar/recipes-secureboot/sb-mok-public/sb-mok-public.bb b/meta-isar/recipes-secureboot/sb-mok-public/sb-mok-public.bb
> new file mode 100644
> index 0000000..46fdeed
> --- /dev/null
> +++ b/meta-isar/recipes-secureboot/sb-mok-public/sb-mok-public.bb
> @@ -0,0 +1,17 @@
> +# Base image recipe for ISAR
> +#
> +# This software is a part of ISAR.
> +# Copyright (C) 2022 Siemens AG
> +
> +inherit dpkg
> +
> +DEPENDS += "sb-mok-keys"
> +DEBIAN_BUILD_DEPENDS .= ",sb-mok-keys"
> +DEBIAN_CONFLICTS .= ",sb-mok-keys"
> +
> +SRC_URI = "file://rules"
> +
> +do_prepare_build[cleandirs] += "${S}/debian"
> +do_prepare_build() {
> +    deb_debianize
> +}

-- 
Siemens AG, Technology
Competence Center Embedded Linux