Hello, chayleaf writes: > Wouldn't it be fine if the key is stored on an external device and the > user supplies a G-Expression that loads it? Or is the G-Expression > executed at reconfigure as opposed to at boot? It would indeed be fine. The open-luks-device g-exp is executed at boot, in early userspace (ie no root mounted yet, still in the initramfs), by `build-system` in (gnu build linux-boot) as a member of `pre-mount`. > Storing the key itself is indeed insecure. However, I think the > ability to load the key from something other than user input could > become a building block for hardcoding the key in more secure ways. > For example, as far as I can tell, Grub supports multiple initrd > images [1], if the user puts their key on the boot partition in the > cpio format and tells Grub to use it as a secondary initrd, perhaps it > could be done. Yes, this is what I was suggesting, although I don't really know how Linux handles multiple initrds. Is the resulting initramfs a union of the different initrds? > I do agree that at the very least the potential security issues > hardcoding the key can cause need to be documented. Agreed. > The biggest problem is there need to be multiple generations available > at the same time. While you could create a separate "private" only- > read-by-root initrd store for this purpose, that would be too much work > for just a single feature. A possible compromise is maintaining a > single out-of-store initrd at a given time, or, combined with the > above, the "secret" initrd parts could be stored in a separate archive, > similar to how grub resides in its own directory outside of the store. Out-of-store that's specified by the user seems like a good idea. Do you think you could handle adding additional initrd support to GRUB? I don't think it should be that hard. Apart from that, the patch would be ok to merge for me if there was some accompanying documentation that describes the security risks in a way that would be understable for a layperson. Best, Josselin Poiret