| Message ID | 20240319182026.1571362-9-Quirin.Gylstorff@siemens.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Rework disk encryption | expand |
On 19.03.24 19:18, Quirin Gylstorff wrote: > From: Quirin Gylstorff <quirin.gylstorff@siemens.com> > > Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> > --- > This is a rough example to show that rootfs encryption is possible. > > kas/opt/encrypt_rootfs.yml | 24 ++++++++++++++++++++++++ > wic/x86_64-encryption.wks.in | 18 ++++++++++++++++++ > 2 files changed, 42 insertions(+) > create mode 100644 kas/opt/encrypt_rootfs.yml > create mode 100644 wic/x86_64-encryption.wks.in > > diff --git a/kas/opt/encrypt_rootfs.yml b/kas/opt/encrypt_rootfs.yml > new file mode 100644 > index 0000000..4001c75 > --- /dev/null > +++ b/kas/opt/encrypt_rootfs.yml > @@ -0,0 +1,24 @@ > +# > +# CIP Core, generic profile > +# > +# Copyright (c) Siemens AG, 2024 > +# > +# Authors: > +# Quirin Gylstorff <quirin.gylstorff@siemens.com> > +# > +# SPDX-License-Identifier: MIT > +# > + > +header: > + version: 14 > + > +local_conf_header: > + encrypted_root: | > + WKS_FILE = "x86_64-encryption.wks.in" > + CRYPT_PARTITIONS = "platform:/:reencrypt home:/home:reencrypt var:/var:reencrypt" > + IMAGE_FSTYPES = "wic" > + IMAGER_INSTALL:wic += "systemd-boot" > + CIP_IMAGE_OPTIONS:append:qemu-amd64 = " recipes-core/images/deploy-ovmf.inc" > + INITRAMFS_RECIPE ?= "cip-core-initramfs" > + INITRD_IMAGE = "${INITRAMFS_RECIPE}-${DISTRO}-${MACHINE}.initrd.img" > + do_image_wic[depends] += "${INITRAMFS_RECIPE}:do_build" > diff --git a/wic/x86_64-encryption.wks.in b/wic/x86_64-encryption.wks.in > new file mode 100644 > index 0000000..c143500 > --- /dev/null > +++ b/wic/x86_64-encryption.wks.in > @@ -0,0 +1,18 @@ > +# > +# CIP Core, generic profile > +# > +# Copyright (c) Siemens AG, 2024 > +# > +# SPDX-License-Identifier: MIT > +# > + > +part /boot --source bootimg-efi-isar --sourceparams "loader=systemd-boot,initrd=${INITRD_IMAGE}" --label efi --part-type EF00 --align 1024 --fsuuid 0x4321dcba --uuid cf142945-6fa1-4945-b0f2-b8d6226298c0 > + > +# Not nice use the source param label to supress the root commandline "suppress" Can you elaborate what will happen without this label? Another, wrong "root=..." would be appended? > +part / --source rootfs --fstype ext4 --sourceparams "label=BOOT" --mkfs-extraopts "-T default" --label platform --align 1024 --fsuuid 1f55d66a-40d8-11ee-be56-0242ac120002 --uuid f225331b-2d9c-45a2-bcfe-4a6e86287dfb > +# home and var are extra partitions > +part /home --source rootfs --change-directory=home --fstype=ext4 --label home --align 1024 --size 1G --extra-space=100M --fsuuid 1f55d66a-40d8-11ee-be56-0242ac120002 > +part /var --fstype=ext4 --label var --align 1024 --fixed-size 2G --fsuuid 96be3374-4258-11ee-be56-0242ac120002 > + > +# This works as we know how that the luks device will be named encrypted_<label of the root device> A bit ugly, indeed. Is there no way to let the script set the appropriate root? > +bootloader --ptable gpt --timeout 2 --append "root=/dev/mapper/encrypted_platform console=ttyS0,115200" Jan
On 3/19/24 7:42 PM, Jan Kiszka wrote: > On 19.03.24 19:18, Quirin Gylstorff wrote: >> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> >> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> --- >> This is a rough example to show that rootfs encryption is possible. >> >> kas/opt/encrypt_rootfs.yml | 24 ++++++++++++++++++++++++ >> wic/x86_64-encryption.wks.in | 18 ++++++++++++++++++ >> 2 files changed, 42 insertions(+) >> create mode 100644 kas/opt/encrypt_rootfs.yml >> create mode 100644 wic/x86_64-encryption.wks.in >> >> diff --git a/kas/opt/encrypt_rootfs.yml b/kas/opt/encrypt_rootfs.yml >> new file mode 100644 >> index 0000000..4001c75 >> --- /dev/null >> +++ b/kas/opt/encrypt_rootfs.yml >> @@ -0,0 +1,24 @@ >> +# >> +# CIP Core, generic profile >> +# >> +# Copyright (c) Siemens AG, 2024 >> +# >> +# Authors: >> +# Quirin Gylstorff <quirin.gylstorff@siemens.com> >> +# >> +# SPDX-License-Identifier: MIT >> +# >> + >> +header: >> + version: 14 >> + >> +local_conf_header: >> + encrypted_root: | >> + WKS_FILE = "x86_64-encryption.wks.in" >> + CRYPT_PARTITIONS = "platform:/:reencrypt home:/home:reencrypt var:/var:reencrypt" >> + IMAGE_FSTYPES = "wic" >> + IMAGER_INSTALL:wic += "systemd-boot" >> + CIP_IMAGE_OPTIONS:append:qemu-amd64 = " recipes-core/images/deploy-ovmf.inc" >> + INITRAMFS_RECIPE ?= "cip-core-initramfs" >> + INITRD_IMAGE = "${INITRAMFS_RECIPE}-${DISTRO}-${MACHINE}.initrd.img" >> + do_image_wic[depends] += "${INITRAMFS_RECIPE}:do_build" >> diff --git a/wic/x86_64-encryption.wks.in b/wic/x86_64-encryption.wks.in >> new file mode 100644 >> index 0000000..c143500 >> --- /dev/null >> +++ b/wic/x86_64-encryption.wks.in >> @@ -0,0 +1,18 @@ >> +# >> +# CIP Core, generic profile >> +# >> +# Copyright (c) Siemens AG, 2024 >> +# >> +# SPDX-License-Identifier: MIT >> +# >> + >> +part /boot --source bootimg-efi-isar --sourceparams "loader=systemd-boot,initrd=${INITRD_IMAGE}" --label efi --part-type EF00 --align 1024 --fsuuid 0x4321dcba --uuid cf142945-6fa1-4945-b0f2-b8d6226298c0 >> + >> +# Not nice use the source param label to supress the root commandline > > "suppress" > > Can you elaborate what will happen without this label? Another, wrong > "root=..." would be appended? Yes the default behaviour from bootimg-efi-isar is to add `root=<uuid>` to the kernel commandline > >> +part / --source rootfs --fstype ext4 --sourceparams "label=BOOT" --mkfs-extraopts "-T default" --label platform --align 1024 --fsuuid 1f55d66a-40d8-11ee-be56-0242ac120002 --uuid f225331b-2d9c-45a2-bcfe-4a6e86287dfb >> +# home and var are extra partitions >> +part /home --source rootfs --change-directory=home --fstype=ext4 --label home --align 1024 --size 1G --extra-space=100M --fsuuid 1f55d66a-40d8-11ee-be56-0242ac120002 >> +part /var --fstype=ext4 --label var --align 1024 --fixed-size 2G --fsuuid 96be3374-4258-11ee-be56-0242ac120002 >> + >> +# This works as we know how that the luks device will be named encrypted_<label of the root device> > > A bit ugly, indeed. Is there no way to let the script set the > appropriate root? We can work with templates for the rootfs label or set the ROOT variable in the initramfs like verity and or abrootfs. The second case would require the initramfs to detect a encrypted root. Quirin > >> +bootloader --ptable gpt --timeout 2 --append "root=/dev/mapper/encrypted_platform console=ttyS0,115200" > Jan >
On 20.03.24 12:41, Gylstorff Quirin wrote: > > > On 3/19/24 7:42 PM, Jan Kiszka wrote: >> On 19.03.24 19:18, Quirin Gylstorff wrote: >>> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>> >>> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>> --- >>> This is a rough example to show that rootfs encryption is possible. >>> >>> kas/opt/encrypt_rootfs.yml | 24 ++++++++++++++++++++++++ >>> wic/x86_64-encryption.wks.in | 18 ++++++++++++++++++ >>> 2 files changed, 42 insertions(+) >>> create mode 100644 kas/opt/encrypt_rootfs.yml >>> create mode 100644 wic/x86_64-encryption.wks.in >>> >>> diff --git a/kas/opt/encrypt_rootfs.yml b/kas/opt/encrypt_rootfs.yml >>> new file mode 100644 >>> index 0000000..4001c75 >>> --- /dev/null >>> +++ b/kas/opt/encrypt_rootfs.yml >>> @@ -0,0 +1,24 @@ >>> +# >>> +# CIP Core, generic profile >>> +# >>> +# Copyright (c) Siemens AG, 2024 >>> +# >>> +# Authors: >>> +# Quirin Gylstorff <quirin.gylstorff@siemens.com> >>> +# >>> +# SPDX-License-Identifier: MIT >>> +# >>> + >>> +header: >>> + version: 14 >>> + >>> +local_conf_header: >>> + encrypted_root: | >>> + WKS_FILE = "x86_64-encryption.wks.in" >>> + CRYPT_PARTITIONS = "platform:/:reencrypt home:/home:reencrypt >>> var:/var:reencrypt" >>> + IMAGE_FSTYPES = "wic" >>> + IMAGER_INSTALL:wic += "systemd-boot" >>> + CIP_IMAGE_OPTIONS:append:qemu-amd64 = " >>> recipes-core/images/deploy-ovmf.inc" >>> + INITRAMFS_RECIPE ?= "cip-core-initramfs" >>> + INITRD_IMAGE = >>> "${INITRAMFS_RECIPE}-${DISTRO}-${MACHINE}.initrd.img" >>> + do_image_wic[depends] += "${INITRAMFS_RECIPE}:do_build" >>> diff --git a/wic/x86_64-encryption.wks.in b/wic/x86_64-encryption.wks.in >>> new file mode 100644 >>> index 0000000..c143500 >>> --- /dev/null >>> +++ b/wic/x86_64-encryption.wks.in >>> @@ -0,0 +1,18 @@ >>> +# >>> +# CIP Core, generic profile >>> +# >>> +# Copyright (c) Siemens AG, 2024 >>> +# >>> +# SPDX-License-Identifier: MIT >>> +# >>> + >>> +part /boot --source bootimg-efi-isar --sourceparams >>> "loader=systemd-boot,initrd=${INITRD_IMAGE}" --label efi --part-type >>> EF00 --align 1024 --fsuuid 0x4321dcba --uuid >>> cf142945-6fa1-4945-b0f2-b8d6226298c0 >>> + >>> +# Not nice use the source param label to supress the root commandline >> >> "suppress" >> >> Can you elaborate what will happen without this label? Another, wrong >> "root=..." would be appended? > Yes the default behaviour from bootimg-efi-isar is to add `root=<uuid>` > to the kernel commandline > Is that a problem of the -isar part in bootimg-efi-isar or also in upstream? Wouldn't it make sense to add some flexibility here? Or can't we ignore that specific "root=" from the command line in the initramfs? >> >>> +part / --source rootfs --fstype ext4 --sourceparams "label=BOOT" >>> --mkfs-extraopts "-T default" --label platform --align 1024 --fsuuid >>> 1f55d66a-40d8-11ee-be56-0242ac120002 --uuid >>> f225331b-2d9c-45a2-bcfe-4a6e86287dfb >>> +# home and var are extra partitions >>> +part /home --source rootfs --change-directory=home --fstype=ext4 >>> --label home --align 1024 --size 1G --extra-space=100M --fsuuid >>> 1f55d66a-40d8-11ee-be56-0242ac120002 >>> +part /var --fstype=ext4 --label var --align 1024 --fixed-size 2G >>> --fsuuid 96be3374-4258-11ee-be56-0242ac120002 >>> + >>> +# This works as we know how that the luks device will be named >>> encrypted_<label of the root device> >> >> A bit ugly, indeed. Is there no way to let the script set the >> appropriate root? > We can work with templates for the rootfs label or set the ROOT variable > in the initramfs like verity and or abrootfs. The second case would > require the initramfs to detect a encrypted root. Yeah, but the effort should be in generic code ideally, not in individual config files like this one here. Jan
Thanks for sharing the example. I'm trying to build the example and test it on my device using an USB as boot media. I am getting Secure Boot Violation error (Invalid signature detected). Is there anything that I have to do to properly set up secure boot? I see that the KAS config automatically include secure boot recipes if encryption is selected. If I disable secure boot from BIOS, I got a "ERROR: Cannot probe watchdog (Unsupported)" error while it tries to boot.
On 3/22/24 1:24 AM, JohnW via lists.cip-project.org wrote: > Thanks for sharing the example. > > I'm trying to build the example and test it on my device using an USB as > boot media. I am getting Secure Boot Violation error (Invalid signature > detected). Is there anything that I have to do to properly set up secure > boot? I see that the KAS config automatically include secure boot > recipes if encryption is selected. The Secure boot certificates used by cip-core are the edk2 snakeoils keys provided by Debian[1],[2]. This is working for the QEMU targets. For hardware you need to provide your own secure boot certificates. see [3] for more information. For testing you can disable secure boot. [1]: https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/recipes-devtools/secure-boot-secrets/secure-boot-snakeoil_0.1.bb?ref_type=heads [2]: https://salsa.debian.org/qemu-team/edk2/-/blob/debian/debian/PkKek-1-snakeoil.pem?ref_type=heads [3]: https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/doc/README.secureboot.md?ref_type=heads > > If I disable secure boot from BIOS, I got a "ERROR: Cannot probe > watchdog (Unsupported)" error while it tries to boot. This sounds like your hardware has no watchdog or the watchdog is not supported by efibootguard with should not be used in the rfc for root file encryption. How did you build the image? This should build an rootfs without efibootguard and with systemd-boot: ``` kas-container build kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/encrypt_rootfs.yml ``` Quirin > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#15395): https://lists.cip-project.org/g/cip-dev/message/15395 > Mute This Topic: https://lists.cip-project.org/mt/105029665/1753640 > Group Owner: cip-dev+owner@lists.cip-project.org > Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129121/1753640/1405269326/xyzzy [quirin.gylstorff@siemens.com] > -=-=-=-=-=-=-=-=-=-=-=- >
> > This should build an rootfs without efibootguard and with systemd-boot: > > ``` > kas-container build > kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/encrypt_rootfs.yml > ``` I tried this build and tried to boot this image from USB with secure boot disabled in BIOS. The boot stuck at > > > EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path > EFI stub: Measured initrd data into PCR9 I currently have a image build based on ISAR with grub boot loader that has secure boot working properly with all of my test devices. Is it possible if I can add the /opt/encrypt_rootfs.yml into that build?
On 3/25/24 6:48 PM, JohnW via lists.cip-project.org wrote: > This should build an rootfs without efibootguard and with systemd-boot: > > ``` > kas-container build > kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/encrypt_rootfs.yml > ``` > > I tried this build and tried to boot this image from USB with secure > boot disabled in BIOS. The boot stuck at > > EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path > EFI stub: Measured initrd data into PCR9 > > I currently have a image build based on ISAR with grub boot loader that > has secure boot working properly with all of my test devices. Is it > possible if I can add the /opt/encrypt_rootfs.yml into that build? This should not be necessary - the only changes necessary to encrypt the rootfs ontop of v2: - using the custom initrd for the initrd changes - CRYPT_PARTITIONS = "platform:/:reencrypt home:/home:reencrypt var:/var:reencrypt" Quirin > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#15413): https://lists.cip-project.org/g/cip-dev/message/15413 > Mute This Topic: https://lists.cip-project.org/mt/105029665/1753640 > Group Owner: cip-dev+owner@lists.cip-project.org > Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129121/1753640/1405269326/xyzzy [quirin.gylstorff@siemens.com] > -=-=-=-=-=-=-=-=-=-=-=- >
diff --git a/kas/opt/encrypt_rootfs.yml b/kas/opt/encrypt_rootfs.yml new file mode 100644 index 0000000..4001c75 --- /dev/null +++ b/kas/opt/encrypt_rootfs.yml @@ -0,0 +1,24 @@ +# +# CIP Core, generic profile +# +# Copyright (c) Siemens AG, 2024 +# +# Authors: +# Quirin Gylstorff <quirin.gylstorff@siemens.com> +# +# SPDX-License-Identifier: MIT +# + +header: + version: 14 + +local_conf_header: + encrypted_root: | + WKS_FILE = "x86_64-encryption.wks.in" + CRYPT_PARTITIONS = "platform:/:reencrypt home:/home:reencrypt var:/var:reencrypt" + IMAGE_FSTYPES = "wic" + IMAGER_INSTALL:wic += "systemd-boot" + CIP_IMAGE_OPTIONS:append:qemu-amd64 = " recipes-core/images/deploy-ovmf.inc" + INITRAMFS_RECIPE ?= "cip-core-initramfs" + INITRD_IMAGE = "${INITRAMFS_RECIPE}-${DISTRO}-${MACHINE}.initrd.img" + do_image_wic[depends] += "${INITRAMFS_RECIPE}:do_build" diff --git a/wic/x86_64-encryption.wks.in b/wic/x86_64-encryption.wks.in new file mode 100644 index 0000000..c143500 --- /dev/null +++ b/wic/x86_64-encryption.wks.in @@ -0,0 +1,18 @@ +# +# CIP Core, generic profile +# +# Copyright (c) Siemens AG, 2024 +# +# SPDX-License-Identifier: MIT +# + +part /boot --source bootimg-efi-isar --sourceparams "loader=systemd-boot,initrd=${INITRD_IMAGE}" --label efi --part-type EF00 --align 1024 --fsuuid 0x4321dcba --uuid cf142945-6fa1-4945-b0f2-b8d6226298c0 + +# Not nice use the source param label to supress the root commandline +part / --source rootfs --fstype ext4 --sourceparams "label=BOOT" --mkfs-extraopts "-T default" --label platform --align 1024 --fsuuid 1f55d66a-40d8-11ee-be56-0242ac120002 --uuid f225331b-2d9c-45a2-bcfe-4a6e86287dfb +# home and var are extra partitions +part /home --source rootfs --change-directory=home --fstype=ext4 --label home --align 1024 --size 1G --extra-space=100M --fsuuid 1f55d66a-40d8-11ee-be56-0242ac120002 +part /var --fstype=ext4 --label var --align 1024 --fixed-size 2G --fsuuid 96be3374-4258-11ee-be56-0242ac120002 + +# This works as we know how that the luks device will be named encrypted_<label of the root device> +bootloader --ptable gpt --timeout 2 --append "root=/dev/mapper/encrypted_platform console=ttyS0,115200"