| Message ID | 20240422141120.577573-5-Quirin.Gylstorff@siemens.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add option to encrypt the rootfs | expand |
On Mon, 2024-04-22 at 16:09 +0200, Quirin Gylstorff wrote: > From: Quirin Gylstorff <quirin.gylstorff@siemens.com> > > This fixes an issue with encrypted rootfs during system reboot. > With the token option it can happen that during reboot the no > valid Luks partition is found and the boot up fails in the initrd. > > Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> > --- > .../initramfs-crypt-hook/files/encrypt_partition.script | 2 > +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/recipes-initramfs/initramfs-crypt- > hook/files/encrypt_partition.script b/recipes-initramfs/initramfs- > crypt-hook/files/encrypt_partition.script > index 51c81f3..685d882 100644 > --- a/recipes-initramfs/initramfs-crypt- > hook/files/encrypt_partition.script > +++ b/recipes-initramfs/initramfs-crypt- > hook/files/encrypt_partition.script > @@ -134,7 +134,7 @@ for partition_set in $partition_sets; do > fi > > if /usr/sbin/cryptsetup luksDump --batch-mode "$partition" \ > - | grep -q "token"; then > + | grep -q "luks2"; then How do we identify "our" partitions in the first place? If I read the code correctly, we still identify by label, which is quite risky. Otherwise we might re-encrypt partitions which are not even under our control. We must either identify by UUID, or at least limit the search to the device that we bootet from (this is known via the systemd BOOT_LOADER_INTERFACE on recent enough ebg versions). Felix > open_tpm2_partition "$part_device" > "$crypt_mount_name" "$tpm_device" > continue > fi
On 4/23/24 11:35 AM, Moessbauer, Felix (T CED OES-DE) wrote: > On Mon, 2024-04-22 at 16:09 +0200, Quirin Gylstorff wrote: >> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> >> This fixes an issue with encrypted rootfs during system reboot. >> With the token option it can happen that during reboot the no >> valid Luks partition is found and the boot up fails in the initrd. >> >> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> --- >> .../initramfs-crypt-hook/files/encrypt_partition.script | 2 >> +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/recipes-initramfs/initramfs-crypt- >> hook/files/encrypt_partition.script b/recipes-initramfs/initramfs- >> crypt-hook/files/encrypt_partition.script >> index 51c81f3..685d882 100644 >> --- a/recipes-initramfs/initramfs-crypt- >> hook/files/encrypt_partition.script >> +++ b/recipes-initramfs/initramfs-crypt- >> hook/files/encrypt_partition.script >> @@ -134,7 +134,7 @@ for partition_set in $partition_sets; do >> fi >> >> if /usr/sbin/cryptsetup luksDump --batch-mode "$partition" \ >> - | grep -q "token"; then >> + | grep -q "luks2"; then > > How do we identify "our" partitions in the first place? If I read the > code correctly, we still identify by label, which is quite risky. > Otherwise we might re-encrypt partitions which are not even under our > control. We cannot identify our partitions- we can use label or uuid which leads to same issue in the long term. > > We must either identify by UUID, UUID can have the same issue as labels if not used correctly. or at least limit the search to the > device that we bootet from (this is known via the systemd > BOOT_LOADER_INTERFACE on recent enough ebg versions). > The encryption should be independent of ebg. > Felix > >> open_tpm2_partition "$part_device" >> "$crypt_mount_name" "$tpm_device" >> continue >> fi >
On Tue, 2024-04-23 at 12:00 +0200, Gylstorff Quirin wrote: > > > On 4/23/24 11:35 AM, Moessbauer, Felix (T CED OES-DE) wrote: > > On Mon, 2024-04-22 at 16:09 +0200, Quirin Gylstorff wrote: > > > From: Quirin Gylstorff <quirin.gylstorff@siemens.com> > > > > > > This fixes an issue with encrypted rootfs during system reboot. > > > With the token option it can happen that during reboot the no > > > valid Luks partition is found and the boot up fails in the > > > initrd. > > > > > > Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> > > > --- > > > .../initramfs-crypt-hook/files/encrypt_partition.script > > > | 2 > > > +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/recipes-initramfs/initramfs-crypt- > > > hook/files/encrypt_partition.script b/recipes- > > > initramfs/initramfs- > > > crypt-hook/files/encrypt_partition.script > > > index 51c81f3..685d882 100644 > > > --- a/recipes-initramfs/initramfs-crypt- > > > hook/files/encrypt_partition.script > > > +++ b/recipes-initramfs/initramfs-crypt- > > > hook/files/encrypt_partition.script > > > @@ -134,7 +134,7 @@ for partition_set in $partition_sets; do > > > fi > > > > > > if /usr/sbin/cryptsetup luksDump --batch-mode > > > "$partition" \ > > > - | grep -q "token"; then > > > + | grep -q "luks2"; then > > > > How do we identify "our" partitions in the first place? If I read > > the > > code correctly, we still identify by label, which is quite risky. > > Otherwise we might re-encrypt partitions which are not even under > > our > > control. > We cannot identify our partitions- we can use label or uuid which > leads > to same issue in the long term. > > > > > We must either identify by UUID, > UUID can have the same issue as labels if not used correctly. Hi, the difference is that UUIDs are (shall be) globally unique - by definition - while labels only need to be unique per device. It's well known that UUIDs in the embedded world are not THAT unique, also for reproducibility reasons. This is still an implementation issue, while label collisions is a design issue, though. Felix > or at least limit the search to the > > device that we bootet from (this is known via the systemd > > BOOT_LOADER_INTERFACE on recent enough ebg versions). > > The encryption should be independent of ebg. > > > > Felix > > > > > open_tpm2_partition "$part_device" > > > "$crypt_mount_name" "$tpm_device" > > > continue > > > fi > >
On 4/24/24 10:00 AM, Moessbauer, Felix (T CED OES-DE) wrote: > On Tue, 2024-04-23 at 12:00 +0200, Gylstorff Quirin wrote: >> >> >> On 4/23/24 11:35 AM, Moessbauer, Felix (T CED OES-DE) wrote: >>> On Mon, 2024-04-22 at 16:09 +0200, Quirin Gylstorff wrote: >>>> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>>> >>>> This fixes an issue with encrypted rootfs during system reboot. >>>> With the token option it can happen that during reboot the no >>>> valid Luks partition is found and the boot up fails in the >>>> initrd. >>>> >>>> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>>> --- >>>> .../initramfs-crypt-hook/files/encrypt_partition.script >>>> | 2 >>>> +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/recipes-initramfs/initramfs-crypt- >>>> hook/files/encrypt_partition.script b/recipes- >>>> initramfs/initramfs- >>>> crypt-hook/files/encrypt_partition.script >>>> index 51c81f3..685d882 100644 >>>> --- a/recipes-initramfs/initramfs-crypt- >>>> hook/files/encrypt_partition.script >>>> +++ b/recipes-initramfs/initramfs-crypt- >>>> hook/files/encrypt_partition.script >>>> @@ -134,7 +134,7 @@ for partition_set in $partition_sets; do >>>> fi >>>> >>>> if /usr/sbin/cryptsetup luksDump --batch-mode >>>> "$partition" \ >>>> - | grep -q "token"; then >>>> + | grep -q "luks2"; then >>> >>> How do we identify "our" partitions in the first place? If I read >>> the >>> code correctly, we still identify by label, which is quite risky. >>> Otherwise we might re-encrypt partitions which are not even under >>> our >>> control. >> We cannot identify our partitions- we can use label or uuid which >> leads >> to same issue in the long term. >> >>> >>> We must either identify by UUID, >> UUID can have the same issue as labels if not used correctly. > > Hi, the difference is that UUIDs are (shall be) globally unique - by > definition - while labels only need to be unique per device. And because of that global uniques UUIDs are not feasible for an automated way to encrypt partitions with the TPM. We need to define and identify the partitions which should be encrypted - independent of the bootloader because the EFI variables only show boot partitions for example data partition are not part of the schema. And using /dev/sdaXm, /dev/mmc0p1,... is also to brittle. Quirin > > It's well known that UUIDs in the embedded world are not THAT unique, > also for reproducibility reasons. This is still an implementation > issue, while label collisions is a design issue, though. > > Felix > >> or at least limit the search to the >>> device that we bootet from (this is known via the systemd >>> BOOT_LOADER_INTERFACE on recent enough ebg versions). >>> The encryption should be independent of ebg. >> >> >>> Felix >>> >>>> open_tpm2_partition "$part_device" >>>> "$crypt_mount_name" "$tpm_device" >>>> continue >>>> fi >>> >
On Wed, 2024-04-24 at 10:22 +0200, Gylstorff Quirin wrote: > > > On 4/24/24 10:00 AM, Moessbauer, Felix (T CED OES-DE) wrote: > > On Tue, 2024-04-23 at 12:00 +0200, Gylstorff Quirin wrote: > > > > > > > > > On 4/23/24 11:35 AM, Moessbauer, Felix (T CED OES-DE) wrote: > > > > On Mon, 2024-04-22 at 16:09 +0200, Quirin Gylstorff wrote: > > > > > From: Quirin Gylstorff <quirin.gylstorff@siemens.com> > > > > > > > > > > This fixes an issue with encrypted rootfs during system > > > > > reboot. > > > > > With the token option it can happen that during reboot the no > > > > > valid Luks partition is found and the boot up fails in the > > > > > initrd. > > > > > > > > > > Signed-off-by: Quirin Gylstorff > > > > > <quirin.gylstorff@siemens.com> > > > > > --- > > > > > .../initramfs-crypt-hook/files/encrypt_partition.script > > > > > > 2 > > > > > +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/recipes-initramfs/initramfs-crypt- > > > > > hook/files/encrypt_partition.script b/recipes- > > > > > initramfs/initramfs- > > > > > crypt-hook/files/encrypt_partition.script > > > > > index 51c81f3..685d882 100644 > > > > > --- a/recipes-initramfs/initramfs-crypt- > > > > > hook/files/encrypt_partition.script > > > > > +++ b/recipes-initramfs/initramfs-crypt- > > > > > hook/files/encrypt_partition.script > > > > > @@ -134,7 +134,7 @@ for partition_set in $partition_sets; do > > > > > fi > > > > > > > > > > if /usr/sbin/cryptsetup luksDump --batch-mode > > > > > "$partition" \ > > > > > - | grep -q "token"; then > > > > > + | grep -q "luks2"; then > > > > > > > > How do we identify "our" partitions in the first place? If I > > > > read > > > > the > > > > code correctly, we still identify by label, which is quite > > > > risky. > > > > Otherwise we might re-encrypt partitions which are not even > > > > under > > > > our > > > > control. > > > We cannot identify our partitions- we can use label or uuid which > > > leads > > > to same issue in the long term. > > > > > > > > > > > We must either identify by UUID, > > > UUID can have the same issue as labels if not used correctly. > > > > Hi, the difference is that UUIDs are (shall be) globally unique - > > by > > definition - while labels only need to be unique per device. > > And because of that global uniques UUIDs are not feasible for an > automated way to encrypt partitions with the TPM. Ok, got it. But then we still need to limit the search to the boot device. > We need to define and > identify the partitions which should be encrypted - independent of > the > bootloader because the EFI variables only show boot partitions for > example data partition are not part of the schema. This is a solved problem. I wrote a similar implementation to detect the "correct" EBG partitions based on the boot partition we get via the BOOT_LOADER_INTERFACE [1]. [1] https://github.com/siemens/efibootguard/commit/ffbd35f76b7ae587211f999a8cbf4514b0ac4ed2 > > And using /dev/sdaXm, /dev/mmc0p1,... is also to brittle. Agree. But just relying on labels is also quite error prone. We saw that when running cip-core tests via MTDA and SD emulation. That's why we added support for the BOOT_LOADER_INTERFACE to EBG in the first place. Felix > > Quirin > > > > It's well known that UUIDs in the embedded world are not THAT > > unique, > > also for reproducibility reasons. This is still an implementation > > issue, while label collisions is a design issue, though. > > > > Felix > > > > > or at least limit the search to the > > > > device that we bootet from (this is known via the systemd > > > > BOOT_LOADER_INTERFACE on recent enough ebg versions). > > > > The encryption should be independent of ebg. > > > > > > > > > > Felix > > > > > > > > > open_tpm2_partition "$part_device" > > > > > "$crypt_mount_name" "$tpm_device" > > > > > continue > > > > > fi > > > > > >
diff --git a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.script b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.script index 51c81f3..685d882 100644 --- a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.script +++ b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.script @@ -134,7 +134,7 @@ for partition_set in $partition_sets; do fi if /usr/sbin/cryptsetup luksDump --batch-mode "$partition" \ - | grep -q "token"; then + | grep -q "luks2"; then open_tpm2_partition "$part_device" "$crypt_mount_name" "$tpm_device" continue fi