| Message ID | 20240823161906.1168642-1-alexander.heinisch@siemens.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [isar-cip-core] Fixing dependency of package expand-on-first-boot on cryptsetup and tss2 (tpm2) libraries when building with disk encryption enabled. | expand |
On 23.08.24 18:19, alexander.heinisch@siemens.com wrote: > From: Alexander Heinisch <alexander.heinisch@siemens.com> > > When building with disk encryption enabled (kas/opt/encrypt-*.yml) the initramfs encrypts > the specified disks if it detects unencrypted disks. > In case of a fresh installation this happens during first boot of the device. > Unfortunately, expand-on-first-boot (kas/opt/expand-on-first-boot.yml) is executed > after the initramfs already encrypted the data partition (in case of *-efibootguard-*.wks.in /var). > Checking if the disk to expand is encrypted got already handled by https://github.com/ilbers/isar/commit/c44c088cd224e44a401410c860bd625f28950ac3 > but dependencies are not automatically set for the package. > Since expand-on-first-boot is hosted in isar and > disk encryption features are enabled with encrypt-partitions override in isar-cip-core, > we extended (.bbappend) on said recipe by adding needed dependencies if this override is set. While the implementation of encryption is handled here, everything that expand-on-first-boot needs to run cryptsetup resize needs to go upstream. I should not matter how the image was encrypted before. > > While the dependency for cryptsetup is obvious, the other dependencies are not! > Here is why: > > From cryptsetup 2.4.0 release notes: > " > Cryptsetup 2.4 adds the possibility to implement token handlers > in external libraries (possibly provided by other projects). > ... > As of cryptsetup 2.4.0 release systemd project already merged upstream > native cryptsetup token handler for its systemd-tpm2 LUKS2 token > released originally in systemd-v248. The token can be created using > systemd-cryptenroll utility and devices may be manipulated either by > systemd-cryptsetup cli or by cryptsetup for actions listed above. > " > ("actions above" include `resize` - see https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/v2.4.0-ReleaseNotes) > Proof: https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/lib/luks2/luks2_token.c#L170 > > For the disk encryption method we use a token `systemd-tpm2` is added to the luks header. > Thus, `cryptsetup resize` uses libcryptsetup-token-systemd-tpm2.so to handle this token > which comes with package `systemd`. > > Following source gives the dependencies on libs: https://github.com/systemd/systemd/blob/a3f17a8f88f7332d0bef67a2d523c41f23f164b6/src/shared/tpm2-util.c#L114 > libtss2-esys.so.0 -> in package libtss2-esys-3.0.2-0 (available for bullseye, bookworm) > libtss2-rc.so.0 -> in package libtss2-rc0 (available for bullseye, bookworm) > libtss2-mu.so.0 -> in package libtss2-mu0 (available for bullseye, bookworm) > > (for buster it seems required libs are packaged in libtss2-esys0 - I did not verify that! - but, > since they are used as alternatives in the initramfs-crypt-hook, I am pretty confident, > nothing too bad will happen at this stage) > > Note: For bullseye-backports and bookworm package systemd already suggests: libtss2-esys-3.0.2-0, libtss2-rc0 and libtss2-mu0 > (For sid packages: libtss2-rc0t64 and libtss2-tcti-device0 are suggested.) > > Thus, I decided to go with packages libtss2-esys-3.0.2-0, libtss2-rc0, libtss2-mu0 and libtss2-esys0 as a (legacy?) fallback for buster. > > Signed-off-by: Alexander Heinisch <alexander.heinisch@siemens.com> > --- > .../expand-on-first-boot_%.bbappend | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > create mode 100644 recipes-support/expand-on-first-boot/expand-on-first-boot_%.bbappend > > diff --git a/recipes-support/expand-on-first-boot/expand-on-first-boot_%.bbappend b/recipes-support/expand-on-first-boot/expand-on-first-boot_%.bbappend > new file mode 100644 > index 0000000..6736fce > --- /dev/null > +++ b/recipes-support/expand-on-first-boot/expand-on-first-boot_%.bbappend > @@ -0,0 +1,16 @@ > +# > +# CIP Core, generic profile > +# > +# Copyright (c) Siemens AG, 2024 > +# > +# Authors: > +# Alexander Heinisch <alexander.heinisch@siemens.com> > +# > +# SPDX-License-Identifier: MIT > +# > + > +DEBIAN_DEPENDS:append:encrypt-partitions = ", cryptsetup, \ > + libtss2-esys-3.0.2-0 | libtss2-esys0, \ > + libtss2-rc0 | libtss2-esys0, \ > + libtss2-mu0 | libtss2-esys0 \ Two issues: - this looks debian release-specific and needs to take that into account - indention is unusual and ugly wide > + " > \ No newline at end of file ...and this should also be avoided. Jan
> > Since expand-on-first-boot is hosted in isar and disk encryption > > features are enabled with encrypt-partitions override in > > isar-cip-core, we extended (.bbappend) on said recipe by adding needed dependencies if this override is set. > > While the implementation of encryption is handled here, everything that expand-on-first-boot needs to run cryptsetup resize needs to go upstream. I should not matter how the image was encrypted before. I was initially preparing a patch for isar. But decided against, because isar does not know about disk-encryption, using tpm2 to store the token nor about the override used to enable disk encryption. > > +DEBIAN_DEPENDS:append:encrypt-partitions = ", cryptsetup, \ > > + libtss2-esys-3.0.2-0 | libtss2-esys0, \ > > + libtss2-rc0 | libtss2-esys0, \ > > + libtss2-mu0 | > > +libtss2-esys0 \ > > Two issues: > - this looks debian release-specific and needs to take that into > account It is! But, since `DISTRO` is not limited to a fixed set of debian releases, I don't see an easy way on how to improve on this. Any suggestions? > - indention is unusual and ugly wide Intention was to put all related packages on single lines while aligning them vertically. I see the amount of whitespace is probably a little overkill ... > > + " > > \ No newline at end of file > ...and this should also be avoided. Sure. BR Alexander
On 26.08.24 14:38, Heinisch, Alexander (T CED SES-AT) wrote: >>> Since expand-on-first-boot is hosted in isar and disk encryption >>> features are enabled with encrypt-partitions override in >>> isar-cip-core, we extended (.bbappend) on said recipe by adding needed dependencies if this override is set. >> >> While the implementation of encryption is handled here, everything that expand-on-first-boot needs to run cryptsetup resize needs to go upstream. I should not matter how the image was encrypted before. > > I was initially preparing a patch for isar. > But decided against, because isar does not know about disk-encryption, using tpm2 to store the token nor about the override used to enable disk encryption. > At least cryptsetup is generic and has nothing to do if a TPM is used or something else. So, this patch will at least have to be split. >>> +DEBIAN_DEPENDS:append:encrypt-partitions = ", cryptsetup, \ >>> + libtss2-esys-3.0.2-0 | libtss2-esys0, \ >>> + libtss2-rc0 | libtss2-esys0, \ >>> + libtss2-mu0 | >>> +libtss2-esys0 \ >> >> Two issues: >> - this looks debian release-specific and needs to take that into >> account > > It is! But, since `DISTRO` is not limited to a fixed set of debian releases, > I don't see an easy way on how to improve on this. Any suggestions? > OVERRIDES contains BASE_DISTRO_CODENAME, and this is already used here as well as in isar itself. >> - indention is unusual and ugly wide > > Intention was to put all related packages on single lines > while aligning them vertically. > I see the amount of whitespace is probably a little overkill ... > VARIABLE = ", \ value1, \ value2, \ " >>> + " >>> \ No newline at end of file > >> ...and this should also be avoided. > > Sure. > > BR Alexander Jan
Short update on this patch. After some discussion we decided to improve this patch in the following way: 1.) Instead of adding additional dependencies used to handle disk expansion in case of encrypted disks by a bbappend, we add a variable (`ADDITIONAL_DISK_ENCRYPTION_PACKAGES`) to extend the dependencies of package expand-on-first-boot_%.bb. That way we don't have to struggle with version matching, or unforseeable changes upstream, still, providing flexibility for downstream projects like isar-cip-core to add the dependencies needed when disk encryption is applied! See: https://groups.google.com/g/isar-users/c/0mc0AGyP3yY 2.) Once patch is applied we have to bump isar-cip-core to isar version containing the patch. 3.) Define `ADDITIONAL_DISK_ENCRYPTION_PACKAGES` in https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/conf/distro/cip-core-common.inc?ref_type=heads 4.) Reuse of `ADDITIONAL_DISK_ENCRYPTION_PACKAGES` in https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.2.bb?ref_type=heads#L12 to ensure consistency on future changes. Patch series follows once patch is approved upstream... BR Alexander
diff --git a/recipes-support/expand-on-first-boot/expand-on-first-boot_%.bbappend b/recipes-support/expand-on-first-boot/expand-on-first-boot_%.bbappend new file mode 100644 index 0000000..6736fce --- /dev/null +++ b/recipes-support/expand-on-first-boot/expand-on-first-boot_%.bbappend @@ -0,0 +1,16 @@ +# +# CIP Core, generic profile +# +# Copyright (c) Siemens AG, 2024 +# +# Authors: +# Alexander Heinisch <alexander.heinisch@siemens.com> +# +# SPDX-License-Identifier: MIT +# + +DEBIAN_DEPENDS:append:encrypt-partitions = ", cryptsetup, \ + libtss2-esys-3.0.2-0 | libtss2-esys0, \ + libtss2-rc0 | libtss2-esys0, \ + libtss2-mu0 | libtss2-esys0 \ + " \ No newline at end of file