allow booting from non-LUKs partition + online conversion/encryption

[coreycothrum]

allow booting from non-LUKs partition + online conversion/encryption

[coreycothrum]

1. Maybe create an extra unencrypted partition and see if we encrypt with this tool

Do you mean using extra mender partitions? I think it should be easy to do so in first boot too. Also sorry I am not sure I understand which tool you mean. Is it mender-luks-util.sh?

This comment was only intended as a test step for using mender-luks-util.sh to encrypt a new partition after first boot.

---

I think you make good points. I think dropping the requirement for booting unencrypted is fine.

My current idea is to use blkid or lsblk -f to check if the file system in a partition is known. if not we can use cryptsetup --init-only. Then we would always cryptsetup --resume-only regardless if the partition file system is known or not. if encryption was already completed, the command would simply fail and we would ignore its result. If not it would continue encrypting meaning previous encryption was interrupted. If we don't care about corruption if first boot is interrupted we could do it in one step. In summary, no we don't really need to use a variable.

Sounds reasonable.

[Alvenix]

1. Support booting w/o a LUKs partition

2. Option to convert to LUKs/encrypt after first boot. Similar to the new reencrypt capability.

This would/could eliminate the need to encrypt the image before provisioning devices.

I am thinking of working on this. I want to check if this is okay with you. My current plan:

1. Add variable to enable encryption on first boot
   1.a If it is enabled image can be used without the encryption script and the build warning to use the script is not shown
2. Before first boot (in mender-luks-init.sh) convert to LUKs
   2.a This mean device will only complete the boot after completing encryption
   2.b I will try to make the converting to luks/reencryption atomic so even if device is restarted it would continue encryption until it is finished.

This basically mean supporting 2 on your point only and excluding 1. I think this plan is relatively simple but I would love to hear your opinion.

[coreycothrum]

It's been awhile since I've thought about this.

What you've proposed sounds reasonable, but it'd like to err on the side of keeping mender-luks-init.sh simple and/or not adding many new configuration variables.

Is doing the encryption in mender-luks-init.sh less complex than making accommodations to boot unencrypted (and then doing the encryption in linux)? I don't know...

---

I intended for mender-luks-util.sh to have this functionality. It has a stubbed out function _encrypt { }.

Can we add this functionality here? In a way that could both be used after linux is booted or in mender-luks-init.sh? I think I'd prefer that over having the logic directly in mener-luks-init.sh.

This might be a good prerequisite step.

1. Maybe create an extra unencrypted partition and see if we encrypt with this tool
2. See if we can install and use this tool in the initramfs

(note/fyi: we're moving/cloning logic from mender-luks-encrypt-image.sh somewhere else it can be used outside the build process)

---

Do we need a separate variable to trigger encrypt on first booth? Can we check if the partition is already LUKS? Or check for the presence of the detached LUKS header or not?

How do we know we're not "first boot" anymore?

---

Is this functionality worth the increase in maintenance and complexity? I don't think it is for me (which is why I've not got around to doing it). I do concede that mender-luks-encrypt-image.sh is sort of a pain to work with though...

Do you think it is for you? I'd like to hear your use case and thoughts.

[Alvenix]

Is doing the encryption in mender-luks-init.sh less complex than making accommodations to boot unencrypted (and then doing the encryption in linux)? I don't know...

Although I am not sure but I would feel so, because we can always assume encryption is always there after boot, and for any changes in the future we don't have to think about cases where we boot unencrypted. In addition, we are doing offline encryption instead of online while disk is in use. I am not about sure implementation complexity for booting unencrypted, but for encrypting on first boot it seems to be relatively simple.

Do we need a separate variable to trigger encrypt on first booth? Can we check if the partition is already LUKS? Or check for the presence of the detached LUKS header or not?
How do we know we're not "first boot" anymore?

My current idea is to use blkid or lsblk -f to check if the file system in a partition is known. if it is known (i.e: not encrypted) we can use cryptsetup --init-only. Then we would always cryptsetup --resume-only regardless if the partition file system is known or not. if encryption was already completed, the command would simply fail and we would ignore its result. If not it would continue encrypting meaning previous encryption was interrupted. If we don't care about corruption if first boot is interrupted we could do it in one step. In summary, no we don't really need to use a variable.

Is this functionality worth the increase in maintenance and complexity? I don't think it is for me (which is why I've not got around to doing it). I do concede that mender-luks-encrypt-image.sh is sort of a pain to work with though...

Do you think it is for you? I'd like to hear your use case and thoughts.

I think it can be useful when image is very large because the image cannot be compressed properly and would take more space in storage because it won't remain as sparse. It is a hassle to store the encrypted image or regenerate it. It also should be more secure to encrypt on first boot. The build wouldn't require sudo too. But I am personally not sure if it is needed but generally it can improve developer experience. (Using it in CICD is annoying too)

I could do all of this using bbappend but I feel it would be better for it to be in the layer itself.

I intended for mender-luks-util.sh to have this functionality. It has a stubbed out function _encrypt { }.

Can we add this functionality here? In a way that could both be used after linux is booted or in mender-luks-init.sh? I think I'd prefer that over having the logic directly in mener-luks-init.sh.

I will try to so!

1. Maybe create an extra unencrypted partition and see if we encrypt with this tool

Do you mean using extra mender partitions? I think it should be easy to do so in first boot too. Also sorry I am not sure I understand which tool you mean. Is it mender-luks-util.sh?

(note/fyi: we're moving/cloning logic from mender-luks-encrypt-image.sh somewhere else it can be used outside the build process)

Yes it could be possible, although I would prefer copying the logic as start as there could be meaningful difference and it would be easier to do so. As side note but I am not sure I understand the script totally. Mainly the luksDump step.