[PATCH 0/5] Initramfs-crypt-hook patches, encryption on update

[PATCH 0/5] Initramfs-crypt-hook patches, encryption on update

[Claudius Heine]

Hi,

I have a couple patches for initramfs-crypt-hook scripts. The first
three are general fixes/cleanup patches and the last two are about
enabling support for encryption via and update, while not touching the
fallback system.

I also have a patch that makes the 'reencrypt' continue, if the power
fails while it happens, but to do that, the initramfs needs to know the
temporary password that was used after a reboot, which currently does
not work with the random temporary passwords used here. My current
solution is to use a static temporary password for the reencryption
process. Any ideas?

kind regards,
Claudius

Claudius Heine (5):
  initramfs-crypt-hook: make sure that mount path exists
  initramfs-crypt-hook: fix inconsistent whitespace
  initramfs-crypt-hook: use real device path in luksFormat case
  initramfs-crypt-hook: implement 'noencrypt' option
  initramfs-crypt-hook: add 'format-if-empty' feature

 doc/README.tpm2.encryption.md                 |  4 +-
 .../files/local-bottom-complete               |  1 +
 .../files/local-top-complete                  | 49 ++++++++++++++++---
 .../initramfs-crypt-hook_0.6.bb               |  2 +-
 4 files changed, 47 insertions(+), 9 deletions(-)

-- 
2.39.5

[PATCH 1/5] initramfs-crypt-hook: make sure that mount path exists

[Claudius Heine]

In case the mount path does not exist, try to create it instead of
failing.

Signed-off-by: Claudius Heine <ch@denx.de>
---
 .../initramfs-crypt-hook/files/local-bottom-complete             | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-bottom-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-bottom-complete
index b991cb4..80553d1 100644
--- a/recipes-initramfs/initramfs-crypt-hook/files/local-bottom-complete
+++ b/recipes-initramfs/initramfs-crypt-hook/files/local-bottom-complete
@@ -41,6 +41,7 @@ mount_partition() {
 	partition_mountpoint=$2
 	[ "$debug" = "y" ] && echo "mount device: '$partition_dev_path' to '$partition_mountpoint'"
 	if ! mountpoint -q "${partition_mountpoint}"; then
+		mkdir -p "${partition_mountpoint}"
 		if ! mount -t "$(get_fstype "${partition_dev_path}")" "${partition_dev_path}" \
 			 "${partition_mountpoint}"; then
 			panic "Can't mount partition '${partition_dev_path}'!"
-- 
2.39.5

[PATCH 2/5] initramfs-crypt-hook: fix inconsistent whitespace

[Claudius Heine]

Signed-off-by: Claudius Heine <ch@denx.de>
---
 recipes-initramfs/initramfs-crypt-hook/files/local-top-complete | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
index 54b8a6e..f1aa0d7 100644
--- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
+++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
@@ -262,7 +262,7 @@ for partition_set in $partition_sets; do
 		;;
 		*)
 			panic "Unknown value ${partition_format}. Cannot create a encrypted partition !"
-		 ;;
+		;;
 	esac
 
 	finalize_tpm2_encryption "$part_device"
-- 
2.39.5

[PATCH 3/5] initramfs-crypt-hook: use real device path in luksFormat case

[Claudius Heine]

In the 'format' case the `$partition` variable is used instead of
`$part_device`, which is likely an error, because all other cases use
`$part_device`.

`$part_device` is the real path to the block device, while `$partition`
is the 'name' of the partition in the `$PARITIONS` variable, as defined
in the recipe.

This fixes an inconsistency, it shouldn't be a bug here, but could
result in bugs when this script is adapted in product layers, etc.

Signed-off-by: Claudius Heine <ch@denx.de>
---
 recipes-initramfs/initramfs-crypt-hook/files/local-top-complete | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
index f1aa0d7..b907ea7 100644
--- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
+++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
@@ -254,7 +254,7 @@ for partition_set in $partition_sets; do
 		"format")
 			log_begin_msg "Encryption of ${part_device}"
 			/usr/sbin/cryptsetup luksFormat --batch-mode \
-				 --type luks2 "$partition" < "$tmp_key"
+				 --type luks2 "$part_device" < "$tmp_key"
 			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"
 			eval "${create_file_system_cmd} ${decrypted_part}"
-- 
2.39.5

[PATCH 4/5] initramfs-crypt-hook: implement 'noencrypt' option

[Claudius Heine]

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
+
+		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 &
-- 
2.39.5

[PATCH 5/5] initramfs-crypt-hook: add 'format-if-empty' feature

[Claudius Heine]

When encryption is enabled from one update to the next there is a
difference between flashing a fresh factory image to a empty storage
device, which contains an empty fallback partition set and updating it,
where the fallback partition contains the actual fallback partitions.

In the update case, the update case, the fallback system should be left
alone and unencrypted.

When doing a factory flash, the fallback partitions can be encrypted.

The best marker on in which case the system is booted is, if the
partition is empty or not. The 'format-if-empty' option will format the
partition with a luks format in case the first 10MiB are empty.

Signed-off-by: Claudius Heine <ch@denx.de>
---
 doc/README.tpm2.encryption.md                    |  3 ++-
 .../files/local-top-complete                     | 16 ++++++++++++++++
 .../initramfs-crypt-hook_0.6.bb                  |  2 +-
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/doc/README.tpm2.encryption.md b/doc/README.tpm2.encryption.md
index 515348a..5fe195d 100644
--- a/doc/README.tpm2.encryption.md
+++ b/doc/README.tpm2.encryption.md
@@ -42,12 +42,13 @@ 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 | format | noencrypt>`.
+Each entry uses the schema `<partition-identifier>:<mountpoint>:<reencrypt | format | noencrypt | format-if-empty>`.
 - 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.
+- `format-if-empty` will create a empty LUKS partition and formats it, like the `format` option, but only if the first 10MiB are empty (contain only 0x00). This makes it possible to differenciate if a partition is empty and can be encrypted, because it was freshly flashed via a factory image, or if it might contain an unencrypted fallback system and should be left alone.
 
 #### 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 1214a63..41598c4 100644
--- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
+++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
@@ -279,6 +279,22 @@ for partition_set in $partition_sets; do
 			eval "${create_file_system_cmd} ${decrypted_part}"
 			log_end_msg
 		;;
+		"format-if-empty")
+			# Check if first 10MiB contain only zeros
+			if cmp -s -n "$(( 10 * 1024 * 1024 ))" "${part_device}" /dev/zero
+			then
+				log_begin_msg "Encryption of ${part_device}"
+				/usr/sbin/cryptsetup luksFormat --batch-mode \
+					 --type luks2 "$part_device" < "$tmp_key"
+				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"
+				eval "${create_file_system_cmd} ${decrypted_part}"
+				log_end_msg
+			else
+				# If not empty, leave it alone.
+				continue
+			fi
+		;;
 		*)
 			panic "Unknown value ${partition_format}. Cannot create a encrypted partition !"
 		;;
diff --git a/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb b/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb
index df335c9..c9a7f89 100644
--- a/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb
+++ b/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb
@@ -41,7 +41,7 @@ HOOK_ADD_MODULES = " \
 
 HOOK_COPY_EXECS = " \
     openssl mke2fs grep awk expr seq sleep basename uuidparse mountpoint \
-    e2fsck resize2fs cryptsetup \
+    e2fsck resize2fs cryptsetup cmp \
     tpm2_pcrread tpm2_testparms tpm2_flushcontext \
     /usr/lib/*/libgcc_s.so.1"
 
-- 
2.39.5

Re: [PATCH 1/5] initramfs-crypt-hook: make sure that mount path exists

[Jan Kiszka]

On 26.02.25 10:59, Claudius Heine wrote:
> In case the mount path does not exist, try to create it instead of
> failing.
> 

Please specify the "why" here. As you know, (almost) every commit
message should cover that, and obvious ones do not even have to talk
about how they do that.

Jan

> Signed-off-by: Claudius Heine <ch@denx.de>
> ---
>  .../initramfs-crypt-hook/files/local-bottom-complete             | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-bottom-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-bottom-complete
> index b991cb4..80553d1 100644
> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-bottom-complete
> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-bottom-complete
> @@ -41,6 +41,7 @@ mount_partition() {
>  	partition_mountpoint=$2
>  	[ "$debug" = "y" ] && echo "mount device: '$partition_dev_path' to '$partition_mountpoint'"
>  	if ! mountpoint -q "${partition_mountpoint}"; then
> +		mkdir -p "${partition_mountpoint}"
>  		if ! mount -t "$(get_fstype "${partition_dev_path}")" "${partition_dev_path}" \
>  			 "${partition_mountpoint}"; then
>  			panic "Can't mount partition '${partition_dev_path}'!"

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH 2/5] initramfs-crypt-hook: fix inconsistent whitespace

[Jan Kiszka]

On 26.02.25 10:59, Claudius Heine wrote:
> Signed-off-by: Claudius Heine <ch@denx.de>
> ---
>  recipes-initramfs/initramfs-crypt-hook/files/local-top-complete | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> index 54b8a6e..f1aa0d7 100644
> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> @@ -262,7 +262,7 @@ for partition_set in $partition_sets; do
>  		;;
>  		*)
>  			panic "Unknown value ${partition_format}. Cannot create a encrypted partition !"
> -		 ;;
> +		;;
>  	esac
>  
>  	finalize_tpm2_encryption "$part_device"

Thanks, applied already.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH 3/5] initramfs-crypt-hook: use real device path in luksFormat case

[Jan Kiszka]

On 26.02.25 10:59, Claudius Heine wrote:
> In the 'format' case the `$partition` variable is used instead of
> `$part_device`, which is likely an error, because all other cases use
> `$part_device`.
> 
> `$part_device` is the real path to the block device, while `$partition`
> is the 'name' of the partition in the `$PARITIONS` variable, as defined
> in the recipe.
> 
> This fixes an inconsistency, it shouldn't be a bug here, but could
> result in bugs when this script is adapted in product layers, etc.
> 
> Signed-off-by: Claudius Heine <ch@denx.de>
> ---
>  recipes-initramfs/initramfs-crypt-hook/files/local-top-complete | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> index f1aa0d7..b907ea7 100644
> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> @@ -254,7 +254,7 @@ for partition_set in $partition_sets; do
>  		"format")
>  			log_begin_msg "Encryption of ${part_device}"
>  			/usr/sbin/cryptsetup luksFormat --batch-mode \
> -				 --type luks2 "$partition" < "$tmp_key"
> +				 --type luks2 "$part_device" < "$tmp_key"
>  			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"
>  			eval "${create_file_system_cmd} ${decrypted_part}"

This goes back to commit 98974a68ab9b, and there it is stated:

+       # clevis does not work with links in /dev/disk*
+       part_device=$(readlink -f "$partition")

So this really looks like a pure consistency cleanup (but a valid one).
Right, Quirin?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH 4/5] initramfs-crypt-hook: implement 'noencrypt' option

[Jan Kiszka]

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

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH 4/5] initramfs-crypt-hook: implement 'noencrypt' option

[Claudius Heine]

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
> 

-- 
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

Re: [PATCH 3/5] initramfs-crypt-hook: use real device path in luksFormat case

[Quirin Gylstorff]

On 2/27/25 10:16, Jan Kiszka wrote:
> On 26.02.25 10:59, Claudius Heine wrote:
>> In the 'format' case the `$partition` variable is used instead of
>> `$part_device`, which is likely an error, because all other cases use
>> `$part_device`.
>>
>> `$part_device` is the real path to the block device, while `$partition`
>> is the 'name' of the partition in the `$PARITIONS` variable, as defined
>> in the recipe.
>>
>> This fixes an inconsistency, it shouldn't be a bug here, but could
>> result in bugs when this script is adapted in product layers, etc.
>>
>> Signed-off-by: Claudius Heine <ch@denx.de>
>> ---
>>   recipes-initramfs/initramfs-crypt-hook/files/local-top-complete | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
>> index f1aa0d7..b907ea7 100644
>> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
>> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
>> @@ -254,7 +254,7 @@ for partition_set in $partition_sets; do
>>   		"format")
>>   			log_begin_msg "Encryption of ${part_device}"
>>   			/usr/sbin/cryptsetup luksFormat --batch-mode \
>> -				 --type luks2 "$partition" < "$tmp_key"
>> +				 --type luks2 "$part_device" < "$tmp_key"
>>   			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"
>>   			eval "${create_file_system_cmd} ${decrypted_part}"
> 
> This goes back to commit 98974a68ab9b, and there it is stated:
> 
> +       # clevis does not work with links in /dev/disk*
> +       part_device=$(readlink -f "$partition")
> 
> So this really looks like a pure consistency cleanup (but a valid one).
> Right, Quirin?
Yes.

Quirin
> 
> Jan
> 

Re: [PATCH 4/5] initramfs-crypt-hook: implement 'noencrypt' option

[Jan Kiszka]

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

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH 3/5] initramfs-crypt-hook: use real device path in luksFormat case

[Jan Kiszka]

On 26.02.25 10:59, Claudius Heine wrote:
> In the 'format' case the `$partition` variable is used instead of
> `$part_device`, which is likely an error, because all other cases use
> `$part_device`.
> 
> `$part_device` is the real path to the block device, while `$partition`
> is the 'name' of the partition in the `$PARITIONS` variable, as defined
> in the recipe.
> 
> This fixes an inconsistency, it shouldn't be a bug here, but could
> result in bugs when this script is adapted in product layers, etc.
> 
> Signed-off-by: Claudius Heine <ch@denx.de>
> ---
>  recipes-initramfs/initramfs-crypt-hook/files/local-top-complete | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> index f1aa0d7..b907ea7 100644
> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> @@ -254,7 +254,7 @@ for partition_set in $partition_sets; do
>  		"format")
>  			log_begin_msg "Encryption of ${part_device}"
>  			/usr/sbin/cryptsetup luksFormat --batch-mode \
> -				 --type luks2 "$partition" < "$tmp_key"
> +				 --type luks2 "$part_device" < "$tmp_key"
>  			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"
>  			eval "${create_file_system_cmd} ${decrypted_part}"

Thanks, applied.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [cip-dev] [PATCH 4/5] initramfs-crypt-hook: implement 'noencrypt' option

[Quirin Gylstorff]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [cip-dev] [PATCH 4/5] initramfs-crypt-hook: implement 'noencrypt' option

[Claudius Heine]

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]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
> 

-- 
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de