Message ID | 20250306093516.3232063-1-gokhan.cetin@siemens.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [isar-cip-core] ebg-secure-boot-signer: convert to signer provider that hooks sign-secure-image | expand |
You are absolutely right, I had checked the signing and import sections for reproducibility, but it is unfortunate that the attributes had signingTime in them when they were exported. I will take it into consideration. Thanks. Gokhan -----Original Message----- From: Kiszka, Jan (FT RPD CED) <jan.kiszka@siemens.com> Sent: Thursday, March 6, 2025 20:25 To: Çetin, Gökhan (FT D EU TR C&E) <gokhan.cetin@siemens.com>; cip-dev@lists.cip-project.org Cc: Gylstorff, Quirin (FT RPD CED OES-DE) <quirin.gylstorff@siemens.com> Subject: Re: [isar-cip-core][PATCH] ebg-secure-boot-signer: convert to signer provider that hooks sign-secure-image On 06.03.25 10:35, Gokhan Cetin wrote: > These changes split the signing process into two stages. > In the first stage, the `sign-secure-image` script called by the > efibootguard wic plugin now uses a hook to create a detached signature. > > This allows downstream layers to provide their own signer scripts in a > similar manner for the second stage, without having to overwrite signer script or partition's source parameter. > > Signed-off-by: Gokhan Cetin <gokhan.cetin@siemens.com> > --- ... > -faketime_cmd="" > -if [ -n "$SOURCE_DATE_EPOCH" ]; then > - faketime_cmd="faketime -f \"$(TZ=UTC date -d @$SOURCE_DATE_EPOCH +'%Y-%m-%d %H:%M:%S')\"" > -fi You are also dropping this, breaking reproducibility (see also [1]). Another reason to carefully refactor while providing reasons, not just replace existing code. Jan [1] https://github.com/rhboot/pesign/issues/125 -- Siemens AG, Foundational Technologies Linux Expert Center
On 06.03.25 14:46, Çetin, Gökhan (FT D EU TR C&E) wrote: > Hi Jan, > > I haven't had a chance to try it directly, but past complaints about using OpenSSL provider/engine together with sbsign's OpenSSL3 support have held us back from maintaining/implementing an custom OpenSSL provider for server side signing. Would be good to have that a bit more concrete. I suppose there is some overlap with what was once done here: https://github.com/phrack/sbsigntools > > In this scenario, pesign is used only for import/export of attributes/signature and this feature makes integration with other tools much easier. > > Since I observed similar signing patterns and toolsets being repeated in different projects, I thought we could upstream it. It is still possible hook different signer recipes/scripts in downstream layers by configuring it on partition's source parameters or installing a different signer recipe so this is not blocker for us and could stay in downstream. I'm not against making users' live easier if downstream has common needs. But the way things were modeled here are not clean yet. And they should not (yet) simply replace the existing sbsigntools path - we have not enough experience with pesign in the field yet while it broke over older versions of EBG. Things I would change: - ebg-secure-boot-signer -> ebg-signer-pesign/sbsign, PREFERRED_PROVIDER to select, default on sbsign for now - secure-boot-secrets -> secure-boot-signature-provider - secure-boot-signature-provider should deliver all what is needed for both variants: certs, keys (where applicable), core signing script; for file-based keys, a standard core script should be provided to all implementers Does that make sense? I may miss some details that you normally only realize while trying to code things yourself. Jan
On 3/6/25 14:46, Çetin, Gökhan (FT D EU TR C&E) wrote: > Hi Jan, > > I haven't had a chance to try it directly, but past complaints about using OpenSSL provider/engine together with sbsign's OpenSSL3 support have held us back from maintaining/implementing an custom OpenSSL provider for server side signing. > > In this scenario, pesign is used only for import/export of attributes/signature and this feature makes integration with other tools much easier. sbsign should replicate that with the option `--detached`. Quirin > > Since I observed similar signing patterns and toolsets being repeated in different projects, I thought we could upstream it. It is still possible hook different signer recipes/scripts in downstream layers by configuring it on partition's source parameters or installing a different signer recipe so this is not blocker for us and could stay in downstream. > > Thanks, > Gokhan > > -----Original Message----- > From: Kiszka, Jan (FT RPD CED) <jan.kiszka@siemens.com> > Sent: Thursday, March 6, 2025 14:48 > To: Gylstorff, Quirin (FT RPD CED OES-DE) <quirin.gylstorff@siemens.com>; Çetin, Gökhan (FT D EU TR C&E) <gokhan.cetin@siemens.com>; cip-dev@lists.cip-project.org > Subject: Re: [isar-cip-core][PATCH] ebg-secure-boot-signer: convert to signer provider that hooks sign-secure-image > > On 06.03.25 12:44, Quirin Gylstorff wrote: >> >> >> On 3/6/25 10:35, Gokhan Cetin wrote: >>> These changes split the signing process into two stages. >>> In the first stage, the `sign-secure-image` script called by the >>> efibootguard wic plugin now uses a hook to create a detached >>> signature. >>> >>> This allows downstream layers to provide their own signer scripts in >>> a similar manner for the second stage, without having to overwrite >>> signer script or partition's source parameter. >>> >> >> This patch does two steps at once: >> - switch to pesign >> - split the signing process >> >> Please separate this steps into two patchsets. Also you need justify >> the switch to pesign. > > We went for sbsign for very strong reasons like its broad usage in distros and the support for OpenSSL which enables e.g. HSM-backed signing. > > Jan > > -- > Siemens AG, Foundational Technologies > Linux Expert Center
On 10.03.25 10:28, Quirin Gylstorff wrote: > > > On 3/6/25 14:46, Çetin, Gökhan (FT D EU TR C&E) wrote: >> Hi Jan, >> >> I haven't had a chance to try it directly, but past complaints about >> using OpenSSL provider/engine together with sbsign's OpenSSL3 support >> have held us back from maintaining/implementing an custom OpenSSL >> provider for server side signing. >> >> In this scenario, pesign is used only for import/export of attributes/ >> signature and this feature makes integration with other tools much >> easier. > > sbsign should replicate that with the option `--detached`. > I'm not sure about that. It creates a detached signature, but it does not allow a third-party tool to sign the attributes section like pesign does. Also the (underdocumented) sbattach does not help here. Jan
> Things I would change: > - ebg-secure-boot-signer -> ebg-signer-pesign/sbsign, > PREFERRED_PROVIDER to select, default on sbsign for now > - secure-boot-secrets -> secure-boot-signature-provider > - secure-boot-signature-provider should deliver all what is needed for > both variants: certs, keys (where applicable), core signing script; > for file-based keys, a standard core script should be provided to all > implementers If core signing script would be part of the PROVIDER recipes, maybe, first thing can be the fixing of `signwith` parameter on the wic plugin, as it is already a customization layer of this chain (as already done with swupdate class and swupdate signer). Or, as you stated, I agree to have both tools available depending on the needs, and until we experience pesign for a while (or other options if available), we can just provide our core signer script from downstream and don't use existing one as there is no direct dependency to it as of now. secure-boot-secrets can be revisited, providing only public certificate is still possible by implementing another provider, but making SB_KEY optional, (or separate -key provider package) could be an option for reusability of existing recipes. On downstream, additionally, we use secure-boot-secrets for signing out-of-tree kernel modules (by providing a kernel module signer which depends secure-boot-secrets), so I would prefer to keep them separated from the secure-boot-signature-provider package. Many thanks. Gokhan -----Original Message----- From: Kiszka, Jan (FT RPD CED) <jan.kiszka@siemens.com> Sent: Monday, March 10, 2025 11:09 To: Çetin, Gökhan (FT D EU TR C&E) <gokhan.cetin@siemens.com>; cip-dev@lists.cip-project.org Cc: Gylstorff, Quirin (FT RPD CED OES-DE) <quirin.gylstorff@siemens.com> Subject: Re: [isar-cip-core][PATCH] ebg-secure-boot-signer: convert to signer provider that hooks sign-secure-image On 06.03.25 14:46, Çetin, Gökhan (FT D EU TR C&E) wrote: > Hi Jan, > > I haven't had a chance to try it directly, but past complaints about using OpenSSL provider/engine together with sbsign's OpenSSL3 support have held us back from maintaining/implementing an custom OpenSSL provider for server side signing. Would be good to have that a bit more concrete. I suppose there is some overlap with what was once done here: https://github.com/phrack/sbsigntools > > In this scenario, pesign is used only for import/export of attributes/signature and this feature makes integration with other tools much easier. > > Since I observed similar signing patterns and toolsets being repeated in different projects, I thought we could upstream it. It is still possible hook different signer recipes/scripts in downstream layers by configuring it on partition's source parameters or installing a different signer recipe so this is not blocker for us and could stay in downstream. I'm not against making users' live easier if downstream has common needs. But the way things were modeled here are not clean yet. And they should not (yet) simply replace the existing sbsigntools path - we have not enough experience with pesign in the field yet while it broke over older versions of EBG. Things I would change: - ebg-secure-boot-signer -> ebg-signer-pesign/sbsign, PREFERRED_PROVIDER to select, default on sbsign for now - secure-boot-secrets -> secure-boot-signature-provider - secure-boot-signature-provider should deliver all what is needed for both variants: certs, keys (where applicable), core signing script; for file-based keys, a standard core script should be provided to all implementers Does that make sense? I may miss some details that you normally only realize while trying to code things yourself. Jan -- Siemens AG, Foundational Technologies Linux Expert Center
On 10.03.25 20:21, Çetin, Gökhan (FT D EU TR C&E) wrote: >> Things I would change: >> - ebg-secure-boot-signer -> ebg-signer-pesign/sbsign, >> PREFERRED_PROVIDER to select, default on sbsign for now >> - secure-boot-secrets -> secure-boot-signature-provider >> - secure-boot-signature-provider should deliver all what is needed for >> both variants: certs, keys (where applicable), core signing script; >> for file-based keys, a standard core script should be provided to all >> implementers > > If core signing script would be part of the PROVIDER recipes, maybe, first thing can be the fixing of `signwith` parameter on the wic plugin, as it is already a customization layer of this chain (as already done with swupdate class and swupdate signer). > Or, as you stated, I agree to have both tools available depending on the needs, and until we experience pesign for a while (or other options if available), > we can just provide our core signer script from downstream and don't use existing one as there is no direct dependency to it as of now. If pesign turns out to be able to obsolete sbsign for our needs, we will eventually be able to drop one - any maybe even folder the signing tools into the wic plugin. But that's not in sight yet. > > secure-boot-secrets can be revisited, providing only public certificate is still possible by implementing another provider, but making SB_KEY optional, (or separate -key provider package) could be an option for reusability of existing recipes. > > On downstream, additionally, we use secure-boot-secrets for signing out-of-tree kernel modules (by providing a kernel module signer which depends secure-boot-secrets), > so I would prefer to keep them separated from the secure-boot-signature-provider package. Now we already have two users of the same interface, and that needs coordination. This can only be done upstream. So present your module signing procedure as well. Did you patch linux/scripts/sign-file.c for that? Jan
> Now we already have two users of the same interface, and that needs coordination. This can only be done upstream. So present your module signing procedure as well. Did you patch linux/scripts/sign-file.c for that? No, but it may not be necessary since sign-file already supports detached signatures. I've introduced a separate build profile for that: https://groups.google.com/g/isar-users/c/QbSnth6G__4 Best, Gokhan -----Original Message----- From: Kiszka, Jan (FT RPD CED) <jan.kiszka@siemens.com> Sent: Monday, March 10, 2025 23:44 To: Çetin, Gökhan (FT D EU TR C&E) <gokhan.cetin@siemens.com>; cip-dev@lists.cip-project.org Cc: Gylstorff, Quirin (FT RPD CED OES-DE) <quirin.gylstorff@siemens.com> Subject: Re: [isar-cip-core][PATCH] ebg-secure-boot-signer: convert to signer provider that hooks sign-secure-image On 10.03.25 20:21, Çetin, Gökhan (FT D EU TR C&E) wrote: >> Things I would change: >> - ebg-secure-boot-signer -> ebg-signer-pesign/sbsign, >> PREFERRED_PROVIDER to select, default on sbsign for now >> - secure-boot-secrets -> secure-boot-signature-provider >> - secure-boot-signature-provider should deliver all what is needed for >> both variants: certs, keys (where applicable), core signing script; >> for file-based keys, a standard core script should be provided to all >> implementers > > If core signing script would be part of the PROVIDER recipes, maybe, first thing can be the fixing of `signwith` parameter on the wic plugin, as it is already a customization layer of this chain (as already done with swupdate class and swupdate signer). > Or, as you stated, I agree to have both tools available depending on > the needs, and until we experience pesign for a while (or other options if available), we can just provide our core signer script from downstream and don't use existing one as there is no direct dependency to it as of now. If pesign turns out to be able to obsolete sbsign for our needs, we will eventually be able to drop one - any maybe even folder the signing tools into the wic plugin. But that's not in sight yet. > > secure-boot-secrets can be revisited, providing only public certificate is still possible by implementing another provider, but making SB_KEY optional, (or separate -key provider package) could be an option for reusability of existing recipes. > > On downstream, additionally, we use secure-boot-secrets for signing > out-of-tree kernel modules (by providing a kernel module signer which depends secure-boot-secrets), so I would prefer to keep them separated from the secure-boot-signature-provider package. Now we already have two users of the same interface, and that needs coordination. This can only be done upstream. So present your module signing procedure as well. Did you patch linux/scripts/sign-file.c for that? Jan -- Siemens AG, Foundational Technologies Linux Expert Center
On 10.03.25 23:14, Çetin, Gökhan (FT D EU TR C&E) wrote: >> Now we already have two users of the same interface, and that needs coordination. This can only be done upstream. So present your module signing procedure as well. Did you patch linux/scripts/sign-file.c for that? > > No, but it may not be necessary since sign-file already supports detached signatures. > I've introduced a separate build profile for that: > https://groups.google.com/g/isar-users/c/QbSnth6G__4 > Too bad that this abstraction just talks about modules. The signer scripts should just be identical for both use cases - and it seems your solution in isar for modules is already a bit more generic than what you proposed here: configurable hash function e.g. Let's generalize that signing procedure in isar, introduce efi signing there, probably to meta/scripts/lib/wic/plugins/source/bootimg-efi.py, and we can simply reuse that here for EBG as well. Jan
Hi Jan, Having identical signer scripts might a bit misleading since it will branch in two different path inside. As signing methods are quite (except hash function and key/cert file) different for both. Module signing requires smime, and considering our project needs, to use same server side signer for this purpose, some hacks and tweaks need to be implemented (e.g. configurable hash just verifies that if requested and offered methods matches). This might also apply to another use cases. That's why I kept them separate. But certainly, common definitions can be generalized as you mentioned. To make the big picture a little clearer, let me show you how it is realized first. I believe it will be easier to refactor it iteratively and move it upstream afterwards. Many thanks. Gokhan -----Original Message----- From: Kiszka, Jan (FT RPD CED) <jan.kiszka@siemens.com> Sent: Tuesday, March 11, 2025 08:52 To: Çetin, Gökhan (FT D EU TR C&E) <gokhan.cetin@siemens.com>; cip-dev@lists.cip-project.org Cc: Gylstorff, Quirin (FT RPD CED OES-DE) <quirin.gylstorff@siemens.com> Subject: Re: [isar-cip-core][PATCH] ebg-secure-boot-signer: convert to signer provider that hooks sign-secure-image On 10.03.25 23:14, Çetin, Gökhan (FT D EU TR C&E) wrote: >> Now we already have two users of the same interface, and that needs coordination. This can only be done upstream. So present your module signing procedure as well. Did you patch linux/scripts/sign-file.c for that? > > No, but it may not be necessary since sign-file already supports detached signatures. > I've introduced a separate build profile for that: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou > ps.google.com%2Fg%2Fisar-users%2Fc%2FQbSnth6G__4&data=05%7C02%7Cgokhan > .cetin%40siemens.com%7C5474db07dad647f5e8c908dd6060de31%7C38ae3bcd9579 > 4fd4addab42e1495d55a%7C1%7C0%7C638772691336690277%7CUnknown%7CTWFpbGZs > b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj > oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=trUSaBAvbA1Py%2BrgekiFqg > UWPNcs9o5T6jYEB5v0hPs%3D&reserved=0 > Too bad that this abstraction just talks about modules. The signer scripts should just be identical for both use cases - and it seems your solution in isar for modules is already a bit more generic than what you proposed here: configurable hash function e.g. Let's generalize that signing procedure in isar, introduce efi signing there, probably to meta/scripts/lib/wic/plugins/source/bootimg-efi.py, and we can simply reuse that here for EBG as well. Jan -- Siemens AG, Foundational Technologies Linux Expert Center
diff --git a/doc/README.secureboot.md b/doc/README.secureboot.md index 8ab67a8..a7dcb6c 100644 --- a/doc/README.secureboot.md +++ b/doc/README.secureboot.md @@ -166,8 +166,8 @@ local_conf_header: INITRAMFS_INSTALL:remove = "initramfs-abrootfs-hook" secure-boot: | - IMAGER_BUILD_DEPS += "ebg-secure-boot-signer" - IMAGER_INSTALL:wic += "ebg-secure-boot-signer" + IMAGER_BUILD_DEPS += "sign-secure-image" + IMAGER_INSTALL:wic += "sign-secure-image" # Use user-generated keys PREFERRED_PROVIDER_secure-boot-secrets = "secure-boot-key" @@ -347,13 +347,30 @@ host$ sudo umount /mnt ``` Launch KeyTool.efi binary from the built in EFI shell and follow step-4 from the section [Add Keys to OVMF](#add-keys-to-ovmf) to inject Secure Boot keys. Otherwise, consult the manual of the specific UEFI Firmware. -Use the recipes [secure-boot-key](###secure-boot-key) to provided the keys -to the signing script contained in -[ebg-secure-boot-signer](###ebg-secure-boot-signer). +### Signing efibootguard and Unified Kernel Image -### [ebg-secure-boot-signer](./recipes-devtools/ebg-secure-boot-signer/ebg-secure-boot-signer_0.2.bb) +Use the recipes +[secure-boot-secrets](###./recipes-devtools/sign-secure-image/secure-boot-secrets) +to provide the secure boot keys to the signing script +[sign-secure-image](./recipes-devtools/sign-secure-image/sign-secure-image_0.1.bb). +`sign-secure-image` exports the attributes from the efi to be signed and requests signature from provided +`ebg-secure-boot-signer` package. Then it imports the signature into the efi and verifies the signed efi with +public key installed by `secure-boot-secrets`. -During building a efibootguard based wic image the scripts contained in -the recipe ebg-secure-boot-signer can be used to sign the bootloader and -unified kernel image(UKI). If the keys are stored in a HSM the script can -be exchanged to sign the artifacts in a more secure way. +This layer provides a signer package +[ebg-secure-boot-signer](./recipes-devtools/ebg-secure-boot-signer/ebg-secure-boot-signer_0.3.bb) +to be used in cases where both public and private keys are accessible at the project directory level. + +If there is a scenario where the private key cannot be accessed, such as HSM based signing or +server side signing, `secure-boot-secrets` and `ebg-secure-boot-signer` can be provided from +downstream layers for project specific requirements. + +``` +PREFERRED_PROVIDER_secure-boot-secrets = "<own secure boot secrets>" +PREFERRED_PROVIDER_ebg-secure-boot-signer = "<own secure boot signer>" +``` + +The package `ebg-secure-boot-signer` must install its signing executable on `/usr/bin/sign-ebg`. +This package may depend `secure-boot-signer` if it needs access to secure boot keys as done in this layer +for signing or verification purposes. In such cases, secure boot keys should always be searched +in designated locations as `secure-boot.pem` and `secure-boot.key` located in `/usr/share/secure-boot-secrets`. diff --git a/kas/opt/ebg-secure-boot-snakeoil.yml b/kas/opt/ebg-secure-boot-snakeoil.yml index 7d8ce65..f1eb782 100644 --- a/kas/opt/ebg-secure-boot-snakeoil.yml +++ b/kas/opt/ebg-secure-boot-snakeoil.yml @@ -25,8 +25,8 @@ local_conf_header: INITRAMFS_INSTALL:remove = "initramfs-abrootfs-hook" secure-boot: | - IMAGER_BUILD_DEPS += "ebg-secure-boot-signer" - IMAGER_INSTALL:wic += "ebg-secure-boot-signer" + IMAGER_BUILD_DEPS += "sign-secure-image" + IMAGER_INSTALL:wic += "sign-secure-image" # Use snakeoil keys PREFERRED_PROVIDER_secure-boot-secrets = "secure-boot-snakeoil" diff --git a/recipes-devtools/ebg-secure-boot-signer/ebg-secure-boot-signer_0.2.bb b/recipes-devtools/ebg-secure-boot-signer/ebg-secure-boot-signer_0.3.bb similarity index 51% rename from recipes-devtools/ebg-secure-boot-signer/ebg-secure-boot-signer_0.2.bb rename to recipes-devtools/ebg-secure-boot-signer/ebg-secure-boot-signer_0.3.bb index 83289d4..3c002e6 100644 --- a/recipes-devtools/ebg-secure-boot-signer/ebg-secure-boot-signer_0.2.bb +++ b/recipes-devtools/ebg-secure-boot-signer/ebg-secure-boot-signer_0.3.bb @@ -1,7 +1,7 @@ # # CIP Core, generic profile # -# Copyright (c) Siemens AG, 2020-2022 +# Copyright (c) Siemens AG, 2020-2025 # # Authors: # Quirin Gylstorff <quirin.gylstorff@siemens.com> @@ -11,17 +11,19 @@ # inherit dpkg-raw +DPKG_ARCH = "all" + +PROVIDES = "ebg-secure-boot-signer" +DEBIAN_PROVIDES = "ebg-secure-boot-signer" DESCRIPTION = "Signing script for EFI Boot Guard setups" DEPENDS = "secure-boot-secrets" -DEBIAN_DEPENDS = "sbsigntool, secure-boot-secrets, faketime" -DPKG_ARCH = "all" +DEBIAN_DEPENDS = "secure-boot-secrets, openssl" -SRC_URI = "file://sign_secure_image.sh" +SRC_URI = "file://sign-ebg.sh" +do_install[cleandirs] = "${D}/usr/bin/" do_install() { - TARGET=${D}/usr/bin - install -d ${TARGET} - install -m 755 ${WORKDIR}/sign_secure_image.sh ${TARGET}/sign_secure_image.sh + install -m 0755 ${WORKDIR}/sign-ebg.sh ${D}/usr/bin/sign-ebg } diff --git a/recipes-devtools/ebg-secure-boot-signer/files/sign-ebg.sh b/recipes-devtools/ebg-secure-boot-signer/files/sign-ebg.sh new file mode 100644 index 0000000..9139165 --- /dev/null +++ b/recipes-devtools/ebg-secure-boot-signer/files/sign-ebg.sh @@ -0,0 +1,34 @@ +#!/bin/sh +# +# CIP Core, generic profile +# +# Copyright (c) Siemens AG, 2020-2025 +# +# Authors: +# Quirin Gylstorff <quirin.gylstorff@siemens.com> +# Jan Kiszka <jan.kiszka@siemens.com> +# +# SPDX-License-Identifier: MIT +# + +set -e + +signee=$1 +signature=$2 + +usage(){ + echo "sign image attributes with secure boot keys" + echo "$0 signee signature" + echo "signee: path to the image attributes to be signed" + echo "signature: path to store the signature" +} + +if [ -z "$signee" ] || [ -z "$signature" ]; then + usage + exit 1 +fi + +keydir=/usr/share/secure-boot-secrets + +openssl dgst -binary -sha256 "${signee}" > "${signee}.digest" +openssl pkeyutl -sign -in "${signee}.digest" -inkey "${keydir}/secure-boot.key" -pkeyopt digest:sha256 -keyform PEM -out "${signature}" diff --git a/recipes-devtools/ebg-secure-boot-signer/files/sign_secure_image.sh b/recipes-devtools/ebg-secure-boot-signer/files/sign_secure_image.sh deleted file mode 100644 index 213cf8a..0000000 --- a/recipes-devtools/ebg-secure-boot-signer/files/sign_secure_image.sh +++ /dev/null @@ -1,38 +0,0 @@ -#!/bin/sh -# -# CIP Core, generic profile -# -# Copyright (c) Siemens AG, 2020-2022 -# -# Authors: -# Quirin Gylstorff <quirin.gylstorff@siemens.com> -# Jan Kiszka <jan.kiszka@siemens.com> -# -# SPDX-License-Identifier: MIT -# - -set -e - -signee=$1 -signed=$2 - -usage(){ - echo "sign with image keys" - echo "$0 signee signed" - echo "signee: path to the image to be signed" - echo "signed: path to store the signed image" -} - -if [ -z "$signee" ] || [ -z "$signed" ]; then - usage - exit 1 -fi - -keydir=/usr/share/secure-boot-secrets - -faketime_cmd="" -if [ -n "$SOURCE_DATE_EPOCH" ]; then - faketime_cmd="faketime -f \"$(TZ=UTC date -d @$SOURCE_DATE_EPOCH +'%Y-%m-%d %H:%M:%S')\"" -fi - -eval $faketime_cmd sbsign --key ${keydir}/secure-boot.key --cert ${keydir}/secure-boot.pem --output $signed $signee diff --git a/recipes-devtools/sign-secure-image/files/sign_secure_image.sh b/recipes-devtools/sign-secure-image/files/sign_secure_image.sh new file mode 100644 index 0000000..8456867 --- /dev/null +++ b/recipes-devtools/sign-secure-image/files/sign_secure_image.sh @@ -0,0 +1,55 @@ +#!/bin/sh +# +# CIP Core, generic profile +# +# Copyright (c) Siemens AG, 2025 +# +# Authors: +# Quirin Gylstorff <quirin.gylstorff@siemens.com> +# Jan Kiszka <jan.kiszka@siemens.com> +# Gokhan Cetin <gokhan.cetin@siemens.com> +# +# SPDX-License-Identifier: MIT +# + +set -e + +signee=$1 +signed=$2 + +usage(){ + echo "sign image with secure boot signer" + echo "$0 signee signed" + echo "signee: path to the image to be signed" + echo "signed: path to store the signed image" +} + +if [ -z "$signee" ] || [ -z "$signed" ]; then + usage + exit 1 +fi + +keydir=/usr/share/secure-boot-secrets + +tmpdir=$(mktemp -d) + +mkdir "${tmpdir}/certdb" +certutil -d "${tmpdir}/certdb" cert.db -A -n cert -t ,,u -i "${keydir}/secure-boot.pem" + +pesign -i "$signee" -E "${tmpdir}/elf.sattrs" + +if [ ! -x /usr/bin/sign-ebg ]; then + echo "Could not find the executable '/usr/bin/sign-ebg'" 1>&2 + exit 1 +fi + +if ! /usr/bin/sign-ebg "${tmpdir}/elf.sattrs" "${tmpdir}/elf.sattrs.sig" ; then + echo "Could not create signature file for '${signee}'" 1>&2 + exit 1 +fi + +pesign -c cert -n "${tmpdir}/certdb" -R "${tmpdir}/elf.sattrs.sig" -I "${tmpdir}/elf.sattrs" -i "$signee" -o "$signed" + +rm -rf "${tmpdir}" + +sbverify "$signed" --cert "${keydir}/secure-boot.pem" diff --git a/recipes-devtools/sign-secure-image/sign-secure-image_0.1.bb b/recipes-devtools/sign-secure-image/sign-secure-image_0.1.bb new file mode 100644 index 0000000..cdc2d16 --- /dev/null +++ b/recipes-devtools/sign-secure-image/sign-secure-image_0.1.bb @@ -0,0 +1,27 @@ +# +# CIP Core, generic profile +# +# Copyright (c) Siemens AG, 2025 +# +# Authors: +# Quirin Gylstorff <quirin.gylstorff@siemens.com> +# Jan Kiszka <jan.kiszka@siemens.com> +# Gokhan Cetin <gokhan.cetin@siemens.com> +# +# SPDX-License-Identifier: MIT +# + +inherit dpkg-raw +DPKG_ARCH = "all" + +DESCRIPTION = "Signing script wrapper for EFI Boot Guard" + +DEPENDS = "secure-boot-secrets ebg-secure-boot-signer" +DEBIAN_DEPENDS = "secure-boot-secrets, ebg-secure-boot-signer, pesign, sbsigntool" + +SRC_URI = "file://sign_secure_image.sh" + +do_install[cleandirs] = "${D}/usr/bin/" +do_install() { + install -m 755 ${WORKDIR}/sign_secure_image.sh ${D}/usr/bin/sign_secure_image.sh +}
These changes split the signing process into two stages. In the first stage, the `sign-secure-image` script called by the efibootguard wic plugin now uses a hook to create a detached signature. This allows downstream layers to provide their own signer scripts in a similar manner for the second stage, without having to overwrite signer script or partition's source parameter. Signed-off-by: Gokhan Cetin <gokhan.cetin@siemens.com> --- doc/README.secureboot.md | 37 +++++++++---- kas/opt/ebg-secure-boot-snakeoil.yml | 4 +- ...r_0.2.bb => ebg-secure-boot-signer_0.3.bb} | 16 +++--- .../ebg-secure-boot-signer/files/sign-ebg.sh | 34 ++++++++++++ .../files/sign_secure_image.sh | 38 ------------- .../files/sign_secure_image.sh | 55 +++++++++++++++++++ .../sign-secure-image_0.1.bb | 27 +++++++++ 7 files changed, 154 insertions(+), 57 deletions(-) rename recipes-devtools/ebg-secure-boot-signer/{ebg-secure-boot-signer_0.2.bb => ebg-secure-boot-signer_0.3.bb} (51%) create mode 100644 recipes-devtools/ebg-secure-boot-signer/files/sign-ebg.sh delete mode 100644 recipes-devtools/ebg-secure-boot-signer/files/sign_secure_image.sh create mode 100644 recipes-devtools/sign-secure-image/files/sign_secure_image.sh create mode 100644 recipes-devtools/sign-secure-image/sign-secure-image_0.1.bb