| Message ID | 20250227143022.323950-3-ch@denx.de (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | initramfs-crypt-hook patch | expand |
On 2/27/25 15:30, 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. The scenario this patch tries to solve is update from A to B: - Update is not confirmed - the encryption was successful - Error occurs and we fallback to Partition A Is that correct? Quirin > > 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 | 24 +++++++++++++++---- > 2 files changed, 21 insertions(+), 6 deletions(-) > > diff --git a/doc/README.tpm2.encryption.md b/doc/README.tpm2.encryption.md > index 3f7e89f..a503095 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, if it isn't encrypted already, but will open it if it is. This makes it possible for an system to support encrypted partitions, 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. For example, with a shared data partition, the fallback system would have the `noencrypt` option, while the encrypted system would have the `reencrypt` option set for it. Now the fallback system can still open the data partition if the update to the encrypted system failed. > > #### 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 502fcc1..67722fc 100644 > --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > @@ -211,22 +211,36 @@ 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 > + 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 &
Hi Qurin, On 2025-02-27 3:42 pm, Quirin Gylstorff wrote: > > > On 2/27/25 15:30, 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. > > The scenario this patch tries to solve is update from A to B: > - Update is not confirmed > - the encryption was successful > - Error occurs and we fallback to Partition A > > Is that correct? Yes, and it is about a shared data partition, that needs to be available on both systems and should eventually be encrypted. The root file systems do not really matter, because they are belong to each update slot. Update slot A needs to be able to mount the encrypted partition, but should not encrypt it. regards, Claudius > > Quirin >> >> 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 | 24 +++++++++++++++---- >> 2 files changed, 21 insertions(+), 6 deletions(-) >> >> diff --git a/doc/README.tpm2.encryption.md b/doc/ >> README.tpm2.encryption.md >> index 3f7e89f..a503095 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, if it isn't >> encrypted already, but will open it if it is. This makes it possible >> for an system to support encrypted partitions, 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. For >> example, with a shared data partition, the fallback system would have >> the `noencrypt` option, while the encrypted system would have the >> `reencrypt` option set for it. Now the fallback system can still open >> the data partition if the update to the encrypted system failed. >> #### 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 502fcc1..67722fc 100644 >> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> @@ -211,22 +211,36 @@ 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 >> + 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 & >
On 2/27/25 15:49, Claudius Heine wrote: > Hi Qurin, > > On 2025-02-27 3:42 pm, Quirin Gylstorff wrote: >> >> >> On 2/27/25 15:30, 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. >> >> The scenario this patch tries to solve is update from A to B: >> - Update is not confirmed >> - the encryption was successful >> - Error occurs and we fallback to Partition A >> >> Is that correct? > > Yes, and it is about a shared data partition, that needs to be available > on both systems and should eventually be encrypted. The root file > systems do not really matter, because they are belong to each update slot. > > Update slot A needs to be able to mount the encrypted partition, but > should not encrypt it. Can you add that example to the commit message. Quirin > > regards, > Claudius > >> >> Quirin >>> >>> 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 | 24 +++++++++++++++---- >>> 2 files changed, 21 insertions(+), 6 deletions(-) >>> >>> diff --git a/doc/README.tpm2.encryption.md b/doc/ >>> README.tpm2.encryption.md >>> index 3f7e89f..a503095 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, if it isn't >>> encrypted already, but will open it if it is. This makes it possible >>> for an system to support encrypted partitions, 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. For >>> example, with a shared data partition, the fallback system would have >>> the `noencrypt` option, while the encrypted system would have the >>> `reencrypt` option set for it. Now the fallback system can still open >>> the data partition if the update to the encrypted system failed. >>> #### 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 502fcc1..67722fc 100644 >>> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >>> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >>> @@ -211,22 +211,36 @@ 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 >>> + 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 & >> >
On 27.02.25 17:07, Quirin Gylstorff wrote: > > > On 2/27/25 15:49, Claudius Heine wrote: >> Hi Qurin, >> >> On 2025-02-27 3:42 pm, Quirin Gylstorff wrote: >>> >>> >>> On 2/27/25 15:30, 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. >>> >>> The scenario this patch tries to solve is update from A to B: >>> - Update is not confirmed >>> - the encryption was successful >>> - Error occurs and we fallback to Partition A >>> >>> Is that correct? >> >> Yes, and it is about a shared data partition, that needs to be >> available on both systems and should eventually be encrypted. The root >> file systems do not really matter, because they are belong to each >> update slot. >> >> Update slot A needs to be able to mount the encrypted partition, but >> should not encrypt it. > > Can you add that example to the commit message. > Actually, that should better go into our documentation so that the reference case is also clear to users not parsing the code history. Jan
On 2025-02-27 5:46 pm, Jan Kiszka wrote: > On 27.02.25 17:07, Quirin Gylstorff wrote: >> >> >> On 2/27/25 15:49, Claudius Heine wrote: >>> Hi Qurin, >>> >>> On 2025-02-27 3:42 pm, Quirin Gylstorff wrote: >>>> >>>> >>>> On 2/27/25 15:30, 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. >>>> >>>> The scenario this patch tries to solve is update from A to B: >>>> - Update is not confirmed >>>> - the encryption was successful >>>> - Error occurs and we fallback to Partition A >>>> >>>> Is that correct? >>> >>> Yes, and it is about a shared data partition, that needs to be >>> available on both systems and should eventually be encrypted. The root >>> file systems do not really matter, because they are belong to each >>> update slot. >>> >>> Update slot A needs to be able to mount the encrypted partition, but >>> should not encrypt it. >> >> Can you add that example to the commit message. >> > > Actually, that should better go into our documentation so that the > reference case is also clear to users not parsing the code history. I have described this scenario in the documentation with in this patch: > For example, with a shared data partition, the fallback system would have the `noencrypt` option, while the encrypted system would have the `reencrypt` option set for it. Now the fallback system can still open the data partition if the update to the encrypted system failed. But maybe I having it more structured instead of just an paragraph would make it easier to consume and understand. regards, Claudius > > Jan >
diff --git a/doc/README.tpm2.encryption.md b/doc/README.tpm2.encryption.md index 3f7e89f..a503095 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, if it isn't encrypted already, but will open it if it is. This makes it possible for an system to support encrypted partitions, 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. For example, with a shared data partition, the fallback system would have the `noencrypt` option, while the encrypted system would have the `reencrypt` option set for it. Now the fallback system can still open the data partition if the update to the encrypted system failed. #### 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 502fcc1..67722fc 100644 --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete @@ -211,22 +211,36 @@ 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 + 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 | 24 +++++++++++++++---- 2 files changed, 21 insertions(+), 6 deletions(-)