-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow booting from non-LUKs partition + online conversion/encryption #16
Comments
I am thinking of working on this. I want to check if this is okay with you. My current plan:
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. |
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 Is doing the encryption in I intended for Can we add this functionality here? In a way that could both be used after linux is booted or in This might be a good prerequisite step.
(note/fyi: we're moving/cloning logic from 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 Do you think it is for you? I'd like to hear your use case and thoughts. |
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.
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.
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 will try to so!
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?
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. |
This comment was only intended as a test step for using I think you make good points. I think dropping the requirement for booting unencrypted is fine.
Sounds reasonable. |
This would/could eliminate the need to encrypt the image before provisioning devices.
The text was updated successfully, but these errors were encountered: