Message ID | 20241220103918.1165341-1-Quirin.Gylstorff@siemens.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [isar-cip-core,RFC] continue boot if not enough disk space for encryption is available. | expand |
On 20.12.24 11:38, Quirin Gylstorff wrote: > From: Quirin Gylstorff <quirin.gylstorff@siemens.com> > > Encrypting a existing system with a full partition will lead to a panic > during resizing. To ensure the availability of the system continue booting > if the flag `CRYPT_ENCRYPTION_OPTIONAL` is set to true. > Is that not overloading the semantic of CRYPT_ENCRYPTION_OPTIONAL? IIRC, it was introduced to handle devices that lack a TPM. What exactly is the scenario we want to handle now? Misconfigurations during image build should not be papered over via CRYPT_ENCRYPTION_OPTIONAL. Jan > Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> > --- > .../initramfs-crypt-hook/files/local-top-complete | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > index 834dea2..f86cade 100644 > --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > @@ -79,7 +79,11 @@ reencrypt_existing_partition() { > EOF > e2fsck -p -f "$1" > if ! resize2fs "$1" "${reduced_size_in_kb}"; then > - panic "reencryption of filesystem $1 cannot continue!" > + if [ "$tpm_encryption_optional" = "true" ]; then > + return 1 > + else > + panic "reencryption of filesystem $1 cannot continue!" > + fi > fi > ;; > squashfs|swap|erofs|"") > @@ -94,6 +98,7 @@ EOF > else > /usr/sbin/cryptsetup reencrypt --encrypt --reduce-device-size "$reduce_device_size"k "$1" < "$2" > fi > + return 0 > } > > expand_partition() { > @@ -236,7 +241,9 @@ for partition_set in $partition_sets; do > case "${partition_format}" in > "reencrypt") > log_begin_msg "Encryption of ${part_device}" > - reencrypt_existing_partition "$part_device" "$tmp_key" > + if ! reencrypt_existing_partition "$part_device" "$tmp_key"; then > + continue > + fi > enroll_tpm2_token "$part_device" "$tmp_key" "$tpm_device" "$tpm_key_algorithm" "$pcr_bank_hash_type" > open_tpm2_partition "$part_device" "$crypt_mount_name" "$tpm_device" > log_end_msg
On 12/20/24 12:03, Jan Kiszka wrote: > On 20.12.24 11:38, Quirin Gylstorff wrote: >> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> >> Encrypting a existing system with a full partition will lead to a panic >> during resizing. To ensure the availability of the system continue booting >> if the flag `CRYPT_ENCRYPTION_OPTIONAL` is set to true. >> > > Is that not overloading the semantic of CRYPT_ENCRYPTION_OPTIONAL? IIRC, > it was introduced to handle devices that lack a TPM. > > What exactly is the scenario we want to handle now? Misconfigurations > during image build should not be papered over via CRYPT_ENCRYPTION_OPTIONAL. The scenario is that we introduce disk encryption via an update for a device in the field and the device has enough customer data on one of the partition that the disk encryption fails. Quirin > > Jan > >> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> --- >> .../initramfs-crypt-hook/files/local-top-complete | 11 +++++++++-- >> 1 file changed, 9 insertions(+), 2 deletions(-) >> >> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> index 834dea2..f86cade 100644 >> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> @@ -79,7 +79,11 @@ reencrypt_existing_partition() { >> EOF >> e2fsck -p -f "$1" >> if ! resize2fs "$1" "${reduced_size_in_kb}"; then >> - panic "reencryption of filesystem $1 cannot continue!" >> + if [ "$tpm_encryption_optional" = "true" ]; then >> + return 1 >> + else >> + panic "reencryption of filesystem $1 cannot continue!" >> + fi >> fi >> ;; >> squashfs|swap|erofs|"") >> @@ -94,6 +98,7 @@ EOF >> else >> /usr/sbin/cryptsetup reencrypt --encrypt --reduce-device-size "$reduce_device_size"k "$1" < "$2" >> fi >> + return 0 >> } >> >> expand_partition() { >> @@ -236,7 +241,9 @@ for partition_set in $partition_sets; do >> case "${partition_format}" in >> "reencrypt") >> log_begin_msg "Encryption of ${part_device}" >> - reencrypt_existing_partition "$part_device" "$tmp_key" >> + if ! reencrypt_existing_partition "$part_device" "$tmp_key"; then >> + continue >> + fi >> enroll_tpm2_token "$part_device" "$tmp_key" "$tpm_device" "$tpm_key_algorithm" "$pcr_bank_hash_type" >> open_tpm2_partition "$part_device" "$crypt_mount_name" "$tpm_device" >> log_end_msg >
On 07.01.25 11:08, Quirin Gylstorff wrote: > > > On 12/20/24 12:03, Jan Kiszka wrote: >> On 20.12.24 11:38, Quirin Gylstorff wrote: >>> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>> >>> Encrypting a existing system with a full partition will lead to a panic >>> during resizing. To ensure the availability of the system continue >>> booting >>> if the flag `CRYPT_ENCRYPTION_OPTIONAL` is set to true. >>> >> >> Is that not overloading the semantic of CRYPT_ENCRYPTION_OPTIONAL? IIRC, >> it was introduced to handle devices that lack a TPM. >> >> What exactly is the scenario we want to handle now? Misconfigurations >> during image build should not be papered over via >> CRYPT_ENCRYPTION_OPTIONAL. > > The scenario is that we introduce disk encryption via an update for a > device in the field and the device has enough customer data on one of > the partition that the disk encryption fails. That insecure scenario that we don't want to promote via upstream? Jan
On 1/7/25 13:52, Jan Kiszka wrote: > On 07.01.25 11:08, Quirin Gylstorff wrote: >> >> >> On 12/20/24 12:03, Jan Kiszka wrote: >>> On 20.12.24 11:38, Quirin Gylstorff wrote: >>>> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>>> >>>> Encrypting a existing system with a full partition will lead to a panic >>>> during resizing. To ensure the availability of the system continue >>>> booting >>>> if the flag `CRYPT_ENCRYPTION_OPTIONAL` is set to true. >>>> >>> >>> Is that not overloading the semantic of CRYPT_ENCRYPTION_OPTIONAL? IIRC, >>> it was introduced to handle devices that lack a TPM. >>> >>> What exactly is the scenario we want to handle now? Misconfigurations >>> during image build should not be papered over via >>> CRYPT_ENCRYPTION_OPTIONAL. >> >> The scenario is that we introduce disk encryption via an update for a >> device in the field and the device has enough customer data on one of >> the partition that the disk encryption fails. > > That insecure scenario that we don't want to promote via upstream? Ok, then lets drop that patch and work on the displayed error message so that the issue is clear for error reporting. I will send a v2 with only an error message. Quirin > > Jan >
diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete index 834dea2..f86cade 100644 --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete @@ -79,7 +79,11 @@ reencrypt_existing_partition() { EOF e2fsck -p -f "$1" if ! resize2fs "$1" "${reduced_size_in_kb}"; then - panic "reencryption of filesystem $1 cannot continue!" + if [ "$tpm_encryption_optional" = "true" ]; then + return 1 + else + panic "reencryption of filesystem $1 cannot continue!" + fi fi ;; squashfs|swap|erofs|"") @@ -94,6 +98,7 @@ EOF else /usr/sbin/cryptsetup reencrypt --encrypt --reduce-device-size "$reduce_device_size"k "$1" < "$2" fi + return 0 } expand_partition() { @@ -236,7 +241,9 @@ for partition_set in $partition_sets; do case "${partition_format}" in "reencrypt") log_begin_msg "Encryption of ${part_device}" - reencrypt_existing_partition "$part_device" "$tmp_key" + if ! reencrypt_existing_partition "$part_device" "$tmp_key"; then + continue + fi enroll_tpm2_token "$part_device" "$tmp_key" "$tpm_device" "$tpm_key_algorithm" "$pcr_bank_hash_type" open_tpm2_partition "$part_device" "$crypt_mount_name" "$tpm_device" log_end_msg