public inbox for cip-dev@lists.cip-project.org
 help / color / mirror / Atom feed
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
To: Claudius Heine <ch@denx.de>,
	cip-dev@lists.cip-project.org,
	Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [PATCH v2 2/4] initramfs-crypt-hook: implement 'noencrypt' option
Date: Thu, 27 Feb 2025 17:07:20 +0100	[thread overview]
Message-ID: <fe273710-8c84-47ce-bcfe-e7df71d9b553@siemens.com> (raw)
In-Reply-To: <01544894-2abd-4f58-ae7f-4ca43e137138@denx.de>



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



  reply	other threads:[~2025-02-27 16:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-27 14:30 [PATCH v2 0/4] initramfs-crypt-hook patch Claudius Heine
2025-02-27 14:30 ` [PATCH v2 1/4] initramfs-crypt-hook: make sure that mount path exists Claudius Heine
2025-02-27 14:30 ` [PATCH v2 2/4] initramfs-crypt-hook: implement 'noencrypt' option Claudius Heine
2025-02-27 14:42   ` Quirin Gylstorff
2025-02-27 14:49     ` Claudius Heine
2025-02-27 16:07       ` Quirin Gylstorff [this message]
2025-02-27 16:46         ` Jan Kiszka
2025-02-27 16:51           ` Claudius Heine
2025-02-27 14:30 ` [PATCH v2 3/4] initramfs-crypt-hook: add 'format-if-empty' feature Claudius Heine
2025-02-27 14:30 ` [PATCH v2 4/4] initramfs-crypt-hook: add re-encryption recovery Claudius Heine
2025-02-27 14:37   ` Quirin Gylstorff
2025-02-27 14:46     ` Claudius Heine
2025-02-27 14:56       ` Quirin Gylstorff
2025-02-27 15:03         ` Claudius Heine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fe273710-8c84-47ce-bcfe-e7df71d9b553@siemens.com \
    --to=quirin.gylstorff@siemens.com \
    --cc=ch@denx.de \
    --cc=cip-dev@lists.cip-project.org \
    --cc=jan.kiszka@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox