| Message ID | 20250226095921.168962-5-ch@denx.de (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Initramfs-crypt-hook patches, encryption on update | expand |
On 26.02.25 10:59, Claudius Heine wrote: > In case encryption needs to be enabled via an update, while still > allowing the update fall back to work. One update step where encryption > is supported, but no reencryption is taking place if the device is not > encrypted. > > For this the `noencrypt` hook is implemented, which requires some > restructure/reordering of the `local-top-complete` script. > > Signed-off-by: Claudius Heine <ch@denx.de> > --- > doc/README.tpm2.encryption.md | 3 +- > .../files/local-top-complete | 29 +++++++++++++++---- > 2 files changed, 26 insertions(+), 6 deletions(-) > > diff --git a/doc/README.tpm2.encryption.md b/doc/README.tpm2.encryption.md > index 3f7e89f..515348a 100644 > --- a/doc/README.tpm2.encryption.md > +++ b/doc/README.tpm2.encryption.md > @@ -42,11 +42,12 @@ The initramfs-crypt-hook recipe has the following variables which can be overwri > ### CRYPT_PARTITIONS > > The variable `CRYPT_PARTITIONS` contains the information which partition shall be encrypted where to mount it. > -Each entry uses the schema `<partition-identifier>:<mountpoint>:<reencrypt or format>`. > +Each entry uses the schema `<partition-identifier>:<mountpoint>:<reencrypt | format | noencrypt>`. > - The `partition-idenitifer` is used to identify the partition on the disk, it can contain a partition label, partition UUID or absolute path to the partition device, e.g. `/dev/sda`. > - The `mountpoint` is used mount the decrypted partition in the root file system > - `reencrypt` uses `cryptsetup reencrypt` to encrypt the exiting content of the partition. This reduces the partition by 32MB and the file system by a similar amount > - `format` creates a empty LUKS partition and creates a file system defined with the shell command given in `CRYPT_CREATE_FILE_SYSTEM_CMD` > +- `noencrypt` will not try to encrypt the partition, it it isn't encrypted already, but will open it if it is. "it it" -> "if it" > This makes it possible for an image to support encrypted systems, while not encrypting anything on their own. Useful when updating from a system that is unencrypted to one that is, while supporting a fallback system. > Please elaborate a bit more on how things are supposed to work this way, which scenarios should be addressed - and which not because they are inherently insecure. > #### Encrypted root file system > > diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > index b907ea7..1214a63 100644 > --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > @@ -216,22 +216,41 @@ for partition_set in $partition_sets; do > if [ ! -e "$part_device" ]; then > panic "Could not find device mapped to '$partition' cannot be encrypted!" > fi > - decrypted_part=/dev/mapper/"$crypt_mount_name" > - # check if we are trying to mount root > - if [ "$partition_mountpoint" = "/" ]; then > - echo "ROOT=$decrypted_part" >/conf/param.conf > - fi > > if [ "$partition_expand" = "expand" ]; then > expand_partition $part_device > fi > > + # If partition is already encrypted, decrypt and continue with next partition: > + decrypted_part=/dev/mapper/"$crypt_mount_name" > if /usr/sbin/cryptsetup luksDump --batch-mode "$part_device" \ > | grep -q "luks2"; then > open_tpm2_partition "$part_device" "$crypt_mount_name" "$tpm_device" > + > + # check if we are trying to mount root, set ROOT to decrypted partition: > + if [ "$partition_mountpoint" = "/" ]; then > + echo "ROOT=$decrypted_part" >/conf/param.conf > + fi > + > continue > fi > > + # If partition should not be encrypted, continue with next partition: > + if [ "$partition_format" = "noencrypt" ] > + then > + # check if we are trying to mount root, set ROOT to plain partition: And this is exactly where all alarms go off: We should not promote the inherently insecure scenario of trying to post-mortem secure the rootfs via an in-field update to encryption unless it is backed by some integrity protection mechanism already (dm-verity in our case). We may encrypt certain data partitions post deployment if data on it is not sensitive or is integrity-protected at application level. I don't see other scenarios here, in the official isar-cip-core layer because they are simply bad practice. > + if [ "$partition_mountpoint" = "/" ]; then > + echo "ROOT=$part_device" >/conf/param.conf > + fi > + > + continue > + fi > + > + # check if we are trying to mount root, set ROOT to decrypted partition: > + if [ "$partition_mountpoint" = "/" ]; then > + echo "ROOT=$decrypted_part" >/conf/param.conf > + fi > + > # service watchdog in the background during lengthy re-encryption > if [ -z "$watchdog_pid" ]; then > service_watchdog & Jan
Hi Jan, On 2025-02-27 10:17 am, Jan Kiszka wrote: > On 26.02.25 10:59, Claudius Heine wrote: >> In case encryption needs to be enabled via an update, while still >> allowing the update fall back to work. One update step where encryption >> is supported, but no reencryption is taking place if the device is not >> encrypted. >> >> For this the `noencrypt` hook is implemented, which requires some >> restructure/reordering of the `local-top-complete` script. >> >> Signed-off-by: Claudius Heine <ch@denx.de> >> --- >> doc/README.tpm2.encryption.md | 3 +- >> .../files/local-top-complete | 29 +++++++++++++++---- >> 2 files changed, 26 insertions(+), 6 deletions(-) >> >> diff --git a/doc/README.tpm2.encryption.md b/doc/README.tpm2.encryption.md >> index 3f7e89f..515348a 100644 >> --- a/doc/README.tpm2.encryption.md >> +++ b/doc/README.tpm2.encryption.md >> @@ -42,11 +42,12 @@ The initramfs-crypt-hook recipe has the following variables which can be overwri >> ### CRYPT_PARTITIONS >> >> The variable `CRYPT_PARTITIONS` contains the information which partition shall be encrypted where to mount it. >> -Each entry uses the schema `<partition-identifier>:<mountpoint>:<reencrypt or format>`. >> +Each entry uses the schema `<partition-identifier>:<mountpoint>:<reencrypt | format | noencrypt>`. >> - The `partition-idenitifer` is used to identify the partition on the disk, it can contain a partition label, partition UUID or absolute path to the partition device, e.g. `/dev/sda`. >> - The `mountpoint` is used mount the decrypted partition in the root file system >> - `reencrypt` uses `cryptsetup reencrypt` to encrypt the exiting content of the partition. This reduces the partition by 32MB and the file system by a similar amount >> - `format` creates a empty LUKS partition and creates a file system defined with the shell command given in `CRYPT_CREATE_FILE_SYSTEM_CMD` >> +- `noencrypt` will not try to encrypt the partition, it it isn't encrypted already, but will open it if it is. > > "it it" -> "if it" > >> This makes it possible for an image to support encrypted systems, while not encrypting anything on their own. Useful when updating from a system that is unencrypted to one that is, while supporting a fallback system. >> > > Please elaborate a bit more on how things are supposed to work this way, > which scenarios should be addressed - and which not because they are > inherently insecure. Well. Switching in-field from an unencrypted system into an encrypted one is inherently insecure. I agree. It seems security requirements have changed in an existing project and now they wanted to add encryption via an update afterwards. If your decision is to NAK this feature, since it promotes insecure approaches, then I can understand. The reason I submitted it here, is because it might be useful for others as well. Eventually encrypting systems is still better than leaving them unencrypted. > >> #### Encrypted root file system >> >> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> index b907ea7..1214a63 100644 >> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> @@ -216,22 +216,41 @@ for partition_set in $partition_sets; do >> if [ ! -e "$part_device" ]; then >> panic "Could not find device mapped to '$partition' cannot be encrypted!" >> fi >> - decrypted_part=/dev/mapper/"$crypt_mount_name" >> - # check if we are trying to mount root >> - if [ "$partition_mountpoint" = "/" ]; then >> - echo "ROOT=$decrypted_part" >/conf/param.conf >> - fi >> >> if [ "$partition_expand" = "expand" ]; then >> expand_partition $part_device >> fi >> >> + # If partition is already encrypted, decrypt and continue with next partition: >> + decrypted_part=/dev/mapper/"$crypt_mount_name" >> if /usr/sbin/cryptsetup luksDump --batch-mode "$part_device" \ >> | grep -q "luks2"; then >> open_tpm2_partition "$part_device" "$crypt_mount_name" "$tpm_device" >> + >> + # check if we are trying to mount root, set ROOT to decrypted partition: >> + if [ "$partition_mountpoint" = "/" ]; then >> + echo "ROOT=$decrypted_part" >/conf/param.conf >> + fi >> + >> continue >> fi >> >> + # If partition should not be encrypted, continue with next partition: >> + if [ "$partition_format" = "noencrypt" ] >> + then >> + # check if we are trying to mount root, set ROOT to plain partition: > > And this is exactly where all alarms go off: We should not promote the > inherently insecure scenario of trying to post-mortem secure the rootfs > via an in-field update to encryption unless it is backed by some > integrity protection mechanism already (dm-verity in our case). > > We may encrypt certain data partitions post deployment if data on it is > not sensitive or is integrity-protected at application level. I don't > see other scenarios here, in the official isar-cip-core layer because > they are simply bad practice. I agree. Security requirements shouldn't just change after a product was released. But apparently that happened in the project where this feature was required. Question here is about if cip-core is trying to deal with it pragmatically and support it, or if cip-core rather wants to demonstrate the best-practice security implementation. I am fine with both options. Thank you and kind regards, Claudius > >> + if [ "$partition_mountpoint" = "/" ]; then >> + echo "ROOT=$part_device" >/conf/param.conf >> + fi >> + >> + continue >> + fi >> + >> + # check if we are trying to mount root, set ROOT to decrypted partition: >> + if [ "$partition_mountpoint" = "/" ]; then >> + echo "ROOT=$decrypted_part" >/conf/param.conf >> + fi >> + >> # service watchdog in the background during lengthy re-encryption >> if [ -z "$watchdog_pid" ]; then >> service_watchdog & > > Jan >
On 27.02.25 10:55, Claudius Heine wrote: > Hi Jan, > > On 2025-02-27 10:17 am, Jan Kiszka wrote: >> On 26.02.25 10:59, Claudius Heine wrote: >>> In case encryption needs to be enabled via an update, while still >>> allowing the update fall back to work. One update step where encryption >>> is supported, but no reencryption is taking place if the device is not >>> encrypted. >>> >>> For this the `noencrypt` hook is implemented, which requires some >>> restructure/reordering of the `local-top-complete` script. >>> >>> Signed-off-by: Claudius Heine <ch@denx.de> >>> --- >>> doc/README.tpm2.encryption.md | 3 +- >>> .../files/local-top-complete | 29 +++++++++++++++---- >>> 2 files changed, 26 insertions(+), 6 deletions(-) >>> >>> diff --git a/doc/README.tpm2.encryption.md b/doc/ >>> README.tpm2.encryption.md >>> index 3f7e89f..515348a 100644 >>> --- a/doc/README.tpm2.encryption.md >>> +++ b/doc/README.tpm2.encryption.md >>> @@ -42,11 +42,12 @@ The initramfs-crypt-hook recipe has the following >>> variables which can be overwri >>> ### CRYPT_PARTITIONS >>> The variable `CRYPT_PARTITIONS` contains the information which >>> partition shall be encrypted where to mount it. >>> -Each entry uses the schema `<partition- >>> identifier>:<mountpoint>:<reencrypt or format>`. >>> +Each entry uses the schema `<partition- >>> identifier>:<mountpoint>:<reencrypt | format | noencrypt>`. >>> - The `partition-idenitifer` is used to identify the partition on >>> the disk, it can contain a partition label, partition UUID or >>> absolute path to the partition device, e.g. `/dev/sda`. >>> - The `mountpoint` is used mount the decrypted partition in the >>> root file system >>> - `reencrypt` uses `cryptsetup reencrypt` to encrypt the exiting >>> content of the partition. This reduces the partition by 32MB and the >>> file system by a similar amount >>> - `format` creates a empty LUKS partition and creates a file system >>> defined with the shell command given in `CRYPT_CREATE_FILE_SYSTEM_CMD` >>> +- `noencrypt` will not try to encrypt the partition, it it isn't >>> encrypted already, but will open it if it is. >> >> "it it" -> "if it" >> >>> This makes it possible for an image to support encrypted systems, >>> while not encrypting anything on their own. Useful when updating from >>> a system that is unencrypted to one that is, while supporting a >>> fallback system. >>> >> >> Please elaborate a bit more on how things are supposed to work this way, >> which scenarios should be addressed - and which not because they are >> inherently insecure. > > Well. Switching in-field from an unencrypted system into an encrypted > one is inherently insecure. I agree. > > It seems security requirements have changed in an existing project and > now they wanted to add encryption via an update afterwards. > > If your decision is to NAK this feature, since it promotes insecure > approaches, then I can understand. > > The reason I submitted it here, is because it might be useful for others > as well. Eventually encrypting systems is still better than leaving them > unencrypted. > >> >>> #### Encrypted root file system >>> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local- >>> top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local- >>> top-complete >>> index b907ea7..1214a63 100644 >>> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >>> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >>> @@ -216,22 +216,41 @@ for partition_set in $partition_sets; do >>> if [ ! -e "$part_device" ]; then >>> panic "Could not find device mapped to '$partition' cannot >>> be encrypted!" >>> fi >>> - decrypted_part=/dev/mapper/"$crypt_mount_name" >>> - # check if we are trying to mount root >>> - if [ "$partition_mountpoint" = "/" ]; then >>> - echo "ROOT=$decrypted_part" >/conf/param.conf >>> - fi >>> if [ "$partition_expand" = "expand" ]; then >>> expand_partition $part_device >>> fi >>> + # If partition is already encrypted, decrypt and continue with >>> next partition: >>> + decrypted_part=/dev/mapper/"$crypt_mount_name" >>> if /usr/sbin/cryptsetup luksDump --batch-mode "$part_device" \ >>> | grep -q "luks2"; then >>> open_tpm2_partition "$part_device" "$crypt_mount_name" >>> "$tpm_device" >>> + >>> + # check if we are trying to mount root, set ROOT to >>> decrypted partition: >>> + if [ "$partition_mountpoint" = "/" ]; then >>> + echo "ROOT=$decrypted_part" >/conf/param.conf >>> + fi >>> + >>> continue >>> fi >>> + # If partition should not be encrypted, continue with next >>> partition: >>> + if [ "$partition_format" = "noencrypt" ] >>> + then >>> + # check if we are trying to mount root, set ROOT to plain >>> partition: >> >> And this is exactly where all alarms go off: We should not promote the >> inherently insecure scenario of trying to post-mortem secure the rootfs >> via an in-field update to encryption unless it is backed by some >> integrity protection mechanism already (dm-verity in our case). >> >> We may encrypt certain data partitions post deployment if data on it is >> not sensitive or is integrity-protected at application level. I don't >> see other scenarios here, in the official isar-cip-core layer because >> they are simply bad practice. > > I agree. Security requirements shouldn't just change after a product was > released. But apparently that happened in the project where this feature > was required. > > Question here is about if cip-core is trying to deal with it > pragmatically and support it, or if cip-core rather wants to demonstrate > the best-practice security implementation. > > I am fine with both options. > Well, as I said, there can be scenarios where encryption could securely work. If we clearly describe them, I'm fine with adding features that are needed to support them - and by chance also scenarios that no one should use for security reasons. But Quirin and I discussed further, and we have more questions regarding your approach and its robustness: Right now, it looks like that isar-cip-core cannot recover from a powercut in the middle of an unfinished encryption. We believe that your approach is equally affected. At the same time, the crypttools should be able to handle that. Maybe we should address that first before adding something that suggest it could provide a recoverable in-field encryption. And please describe HOW all those features should be used. We might have guessed that wrongly why thinking about their shortcomings. Jan
On 2/26/25 10:59, Claudius Heine via lists.cip-project.org wrote: > In case encryption needs to be enabled via an update, while still > allowing the update fall back to work. One update step where encryption > is supported, but no reencryption is taking place if the device is not > encrypted. > > For this the `noencrypt` hook is implemented, which requires some > restructure/reordering of the `local-top-complete` script. > > Signed-off-by: Claudius Heine <ch@denx.de> > --- > doc/README.tpm2.encryption.md | 3 +- > .../files/local-top-complete | 29 +++++++++++++++---- > 2 files changed, 26 insertions(+), 6 deletions(-) > > diff --git a/doc/README.tpm2.encryption.md b/doc/README.tpm2.encryption.md > index 3f7e89f..515348a 100644 > --- a/doc/README.tpm2.encryption.md > +++ b/doc/README.tpm2.encryption.md > @@ -42,11 +42,12 @@ The initramfs-crypt-hook recipe has the following variables which can be overwri > ### CRYPT_PARTITIONS > > The variable `CRYPT_PARTITIONS` contains the information which partition shall be encrypted where to mount it. > -Each entry uses the schema `<partition-identifier>:<mountpoint>:<reencrypt or format>`. > +Each entry uses the schema `<partition-identifier>:<mountpoint>:<reencrypt | format | noencrypt>`. > - The `partition-idenitifer` is used to identify the partition on the disk, it can contain a partition label, partition UUID or absolute path to the partition device, e.g. `/dev/sda`. > - The `mountpoint` is used mount the decrypted partition in the root file system > - `reencrypt` uses `cryptsetup reencrypt` to encrypt the exiting content of the partition. This reduces the partition by 32MB and the file system by a similar amount > - `format` creates a empty LUKS partition and creates a file system defined with the shell command given in `CRYPT_CREATE_FILE_SYSTEM_CMD` > +- `noencrypt` will not try to encrypt the partition, it it isn't encrypted already, but will open it if it is. This makes it possible for an image to support encrypted systems, while not encrypting anything on their own. Useful when updating from a system that is unencrypted to one that is, while supporting a fallback system. > > #### Encrypted root file system > > diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > index b907ea7..1214a63 100644 > --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > @@ -216,22 +216,41 @@ for partition_set in $partition_sets; do > if [ ! -e "$part_device" ]; then > panic "Could not find device mapped to '$partition' cannot be encrypted!" > fi > - decrypted_part=/dev/mapper/"$crypt_mount_name" > - # check if we are trying to mount root > - if [ "$partition_mountpoint" = "/" ]; then > - echo "ROOT=$decrypted_part" >/conf/param.conf > - fi > > if [ "$partition_expand" = "expand" ]; then > expand_partition $part_device > fi > > + # If partition is already encrypted, decrypt and continue with next partition: > + decrypted_part=/dev/mapper/"$crypt_mount_name" > if /usr/sbin/cryptsetup luksDump --batch-mode "$part_device" \ > | grep -q "luks2"; then > open_tpm2_partition "$part_device" "$crypt_mount_name" "$tpm_device" > + > + # check if we are trying to mount root, set ROOT to decrypted partition: > + if [ "$partition_mountpoint" = "/" ]; then > + echo "ROOT=$decrypted_part" >/conf/param.conf > + fi > + > continue > fi > > + # If partition should not be encrypted, continue with next partition: > + if [ "$partition_format" = "noencrypt" ] > + then > + # check if we are trying to mount root, set ROOT to plain partition: > + if [ "$partition_mountpoint" = "/" ]; then > + echo "ROOT=$part_device" >/conf/param.conf > + fi Is this check really necessary? In case root is not encrypted the Root partition should be given by abrootfs/verity/cmdline ? Quirin > + > + continue > + fi > + > + # check if we are trying to mount root, set ROOT to decrypted partition: > + if [ "$partition_mountpoint" = "/" ]; then > + echo "ROOT=$decrypted_part" >/conf/param.conf > + fi > + > # service watchdog in the background during lengthy re-encryption > if [ -z "$watchdog_pid" ]; then > service_watchdog & > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#17922): https://lists.cip-project.org/g/cip-dev/message/17922 > Mute This Topic: https://lists.cip-project.org/mt/111393564/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] > -=-=-=-=-=-=-=-=-=-=-=- >
Hi Quirin, On 2025-02-27 2:16 pm, Quirin Gylstorff wrote: > > > On 2/26/25 10:59, Claudius Heine via lists.cip-project.org wrote: >> In case encryption needs to be enabled via an update, while still >> allowing the update fall back to work. One update step where encryption >> is supported, but no reencryption is taking place if the device is not >> encrypted. >> >> For this the `noencrypt` hook is implemented, which requires some >> restructure/reordering of the `local-top-complete` script. >> >> Signed-off-by: Claudius Heine <ch@denx.de> >> --- >> doc/README.tpm2.encryption.md | 3 +- >> .../files/local-top-complete | 29 +++++++++++++++---- >> 2 files changed, 26 insertions(+), 6 deletions(-) >> >> diff --git a/doc/README.tpm2.encryption.md b/doc/ >> README.tpm2.encryption.md >> index 3f7e89f..515348a 100644 >> --- a/doc/README.tpm2.encryption.md >> +++ b/doc/README.tpm2.encryption.md >> @@ -42,11 +42,12 @@ The initramfs-crypt-hook recipe has the following >> variables which can be overwri >> ### CRYPT_PARTITIONS >> The variable `CRYPT_PARTITIONS` contains the information which >> partition shall be encrypted where to mount it. >> -Each entry uses the schema `<partition- >> identifier>:<mountpoint>:<reencrypt or format>`. >> +Each entry uses the schema `<partition- >> identifier>:<mountpoint>:<reencrypt | format | noencrypt>`. >> - The `partition-idenitifer` is used to identify the partition on >> the disk, it can contain a partition label, partition UUID or absolute >> path to the partition device, e.g. `/dev/sda`. >> - The `mountpoint` is used mount the decrypted partition in the root >> file system >> - `reencrypt` uses `cryptsetup reencrypt` to encrypt the exiting >> content of the partition. This reduces the partition by 32MB and the >> file system by a similar amount >> - `format` creates a empty LUKS partition and creates a file system >> defined with the shell command given in `CRYPT_CREATE_FILE_SYSTEM_CMD` >> +- `noencrypt` will not try to encrypt the partition, it it isn't >> encrypted already, but will open it if it is. This makes it possible >> for an image to support encrypted systems, while not encrypting >> anything on their own. Useful when updating from a system that is >> unencrypted to one that is, while supporting a fallback system. >> #### Encrypted root file system >> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top- >> complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top- >> complete >> index b907ea7..1214a63 100644 >> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> @@ -216,22 +216,41 @@ for partition_set in $partition_sets; do >> if [ ! -e "$part_device" ]; then >> panic "Could not find device mapped to '$partition' cannot >> be encrypted!" >> fi >> - decrypted_part=/dev/mapper/"$crypt_mount_name" >> - # check if we are trying to mount root >> - if [ "$partition_mountpoint" = "/" ]; then >> - echo "ROOT=$decrypted_part" >/conf/param.conf >> - fi >> if [ "$partition_expand" = "expand" ]; then >> expand_partition $part_device >> fi >> + # If partition is already encrypted, decrypt and continue with >> next partition: >> + decrypted_part=/dev/mapper/"$crypt_mount_name" >> if /usr/sbin/cryptsetup luksDump --batch-mode "$part_device" \ >> | grep -q "luks2"; then >> open_tpm2_partition "$part_device" "$crypt_mount_name" >> "$tpm_device" >> + >> + # check if we are trying to mount root, set ROOT to decrypted >> partition: >> + if [ "$partition_mountpoint" = "/" ]; then >> + echo "ROOT=$decrypted_part" >/conf/param.conf >> + fi >> + >> continue >> fi >> + # If partition should not be encrypted, continue with next >> partition: >> + if [ "$partition_format" = "noencrypt" ] >> + then >> + # check if we are trying to mount root, set ROOT to plain >> partition: >> + if [ "$partition_mountpoint" = "/" ]; then >> + echo "ROOT=$part_device" >/conf/param.conf >> + fi > Is this check really necessary? In case root is not encrypted the Root > partition should be given by abrootfs/verity/cmdline ? Good point. > > Quirin >> + >> + continue >> + fi >> + >> + # check if we are trying to mount root, set ROOT to decrypted >> partition: >> + if [ "$partition_mountpoint" = "/" ]; then >> + echo "ROOT=$decrypted_part" >/conf/param.conf >> + fi >> + >> # service watchdog in the background during lengthy re-encryption >> if [ -z "$watchdog_pid" ]; then >> service_watchdog & >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#17922): https://lists.cip-project.org/g/cip-dev/ >> message/17922 >> Mute This Topic: https://lists.cip-project.org/mt/111393564/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/doc/README.tpm2.encryption.md b/doc/README.tpm2.encryption.md index 3f7e89f..515348a 100644 --- a/doc/README.tpm2.encryption.md +++ b/doc/README.tpm2.encryption.md @@ -42,11 +42,12 @@ The initramfs-crypt-hook recipe has the following variables which can be overwri ### CRYPT_PARTITIONS The variable `CRYPT_PARTITIONS` contains the information which partition shall be encrypted where to mount it. -Each entry uses the schema `<partition-identifier>:<mountpoint>:<reencrypt or format>`. +Each entry uses the schema `<partition-identifier>:<mountpoint>:<reencrypt | format | noencrypt>`. - The `partition-idenitifer` is used to identify the partition on the disk, it can contain a partition label, partition UUID or absolute path to the partition device, e.g. `/dev/sda`. - The `mountpoint` is used mount the decrypted partition in the root file system - `reencrypt` uses `cryptsetup reencrypt` to encrypt the exiting content of the partition. This reduces the partition by 32MB and the file system by a similar amount - `format` creates a empty LUKS partition and creates a file system defined with the shell command given in `CRYPT_CREATE_FILE_SYSTEM_CMD` +- `noencrypt` will not try to encrypt the partition, it it isn't encrypted already, but will open it if it is. This makes it possible for an image to support encrypted systems, while not encrypting anything on their own. Useful when updating from a system that is unencrypted to one that is, while supporting a fallback system. #### Encrypted root file system diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete index b907ea7..1214a63 100644 --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete @@ -216,22 +216,41 @@ for partition_set in $partition_sets; do if [ ! -e "$part_device" ]; then panic "Could not find device mapped to '$partition' cannot be encrypted!" fi - decrypted_part=/dev/mapper/"$crypt_mount_name" - # check if we are trying to mount root - if [ "$partition_mountpoint" = "/" ]; then - echo "ROOT=$decrypted_part" >/conf/param.conf - fi if [ "$partition_expand" = "expand" ]; then expand_partition $part_device fi + # If partition is already encrypted, decrypt and continue with next partition: + decrypted_part=/dev/mapper/"$crypt_mount_name" if /usr/sbin/cryptsetup luksDump --batch-mode "$part_device" \ | grep -q "luks2"; then open_tpm2_partition "$part_device" "$crypt_mount_name" "$tpm_device" + + # check if we are trying to mount root, set ROOT to decrypted partition: + if [ "$partition_mountpoint" = "/" ]; then + echo "ROOT=$decrypted_part" >/conf/param.conf + fi + continue fi + # If partition should not be encrypted, continue with next partition: + if [ "$partition_format" = "noencrypt" ] + then + # check if we are trying to mount root, set ROOT to plain partition: + if [ "$partition_mountpoint" = "/" ]; then + echo "ROOT=$part_device" >/conf/param.conf + fi + + continue + fi + + # check if we are trying to mount root, set ROOT to decrypted partition: + if [ "$partition_mountpoint" = "/" ]; then + echo "ROOT=$decrypted_part" >/conf/param.conf + fi + # service watchdog in the background during lengthy re-encryption if [ -z "$watchdog_pid" ]; then service_watchdog &
In case encryption needs to be enabled via an update, while still allowing the update fall back to work. One update step where encryption is supported, but no reencryption is taking place if the device is not encrypted. For this the `noencrypt` hook is implemented, which requires some restructure/reordering of the `local-top-complete` script. Signed-off-by: Claudius Heine <ch@denx.de> --- doc/README.tpm2.encryption.md | 3 +- .../files/local-top-complete | 29 +++++++++++++++---- 2 files changed, 26 insertions(+), 6 deletions(-)