migrating from genkernel to ??? - full disc encryption

[oxensepp]

Hello,

I noticed that genkernel is unmaintained, so it's future seems uncertain and I am thinking about migrating to another setup.
I used it to generate my kernel and initramfs. Further, I use grub as bootloader (EFI mode).

I have a full disc encryption. That means, EFI and BOOT are on an USB stick. BOOT is luks1 encrypted, and the bootloader decrypts BOOT.
Also, the rootfs and swap are on an luks 2 encrypted volume. Key and header for it are detached and reside in BOOT.
Therefore, while init the system must decrypt the rootfs.


Reading the gentoo docs, installkernel and dracut seem the new 'standard', expecially, when one wants also use a distribution kernel.
So I tried installkernel/dracut (and still grub), but dracut seems not to support my setup, at least not without dracut hacking (https://forums.gentoo.org/viewtopic-t-1175404.html)

So I am asking for alternatives? Are there any?

Does someone run a similar setup, and how is it working in detail?

[zen_desu]

Hello,

I noticed that genkernel is unmaintained, so it's future seems uncertain and I am thinking about migrating to another setup.
I used it to generate my kernel and initramfs. Further, I use grub as bootloader (EFI mode).

I have a full disc encryption. That means, EFI and BOOT are on an USB stick. BOOT is luks1 encrypted, and the bootloader decrypts BOOT.
Also, the rootfs and swap are on an luks 2 encrypted volume. Key and header for it are detached and reside in BOOT.
Therefore, while init the system must decrypt the rootfs.


Reading the gentoo docs, installkernel and dracut seem the new 'standard', expecially, when one wants also use a distribution kernel.
So I tried installkernel/dracut (and still grub), but dracut seems not to support my setup, at least not without dracut hacking (https://forums.gentoo.org/viewtopic-t-1175404.html)

So I am asking for alternatives? Are there any?

Does someone run a similar setup, and how is it working in detail?

https://wiki.gentoo.org/wiki/Rootfs_encryption#UGRD

you can try this

https://github.com/desultory/ugrd/blob/ ... cryptsetup

it should mostly just work for you, but you'll need to configure the header location. If you're using an encrypted boot i'd just have them included in the initramfs itself. ugrd isn't really designed to handle luks1 but can be forced to (there is no way to validate luks1 headers reasonably).

I'd recommend dropping the encrypted boot stuff, it mostly gets in the way and doesn't really add much if any security (especially when you're having to use luks1 or pbkdf to make it work)

[sublogic]

I noticed that genkernel is unmaintained, so it's future seems uncertain and I am thinking about migrating to another setup.
I used it to generate my kernel and initramfs. Further, I use grub as bootloader (EFI mode).

If you can't convince dracut or ugrd to support your setup, here's another path.

Identify the drivers that are necessary to mount the root filesystem. Rebuild your kernel with those drivers built-in, rather than as modules. You can run lsmod from single-user mode to get an idea. Once you do that, your kernel and initramfs are decoupled and your current initramfs, from genkernel, can boot your future kernels. From now on, you build your kernels manually instead of going through genkernel.

My boot partition has a /boot/initramfs-generic from genkernel, that I think dates back to linux-5.15.19. A slight abuse of grub configuration fools grub-mkconfig into using it on all kernels:

Code: Select all

# use a kernel-independent initramfs
# (see /etc/grub.d/10_linux)
GRUB_EARLY_INITRD_LINUX_CUSTOM="initramfs-generic"
...

Ask again if you choose this path and need more details.

[pietinger]

oxensepp,

as someone who has been configuring his own kernel for many years, I can understand and endorse @sublogic's recommendation. But I would like to point out that the initial configuration of a kernel can be very time-consuming (especially if you want a hardened kernel). To get an idea of this, I recommend my wiki article:
https://wiki.gentoo.org/wiki/User:Pieti ... figuration

Also, a note to @sublogic: If you already have a working initramfs, you've basically won, because... it can be unpacked and checked at any time. You may then also find the unnecessary inclusion of kernel modules that are no longer needed (because you have configured them as built-in):
https://wiki.gentoo.org/wiki/User:Pieti ... _CPIO_file
... or perhaps the entire article because I have described all 4 options to create manually an initramfs; to "repack" an unpacked initramfs you will need the 4th option: https://wiki.gentoo.org/wiki/User:Pieti ... _directory

[oxensepp]

https://wiki.gentoo.org/wiki/Rootfs_encryption#UGRD

you can try this

https://github.com/desultory/ugrd/blob/ ... cryptsetup

it should mostly just work for you, but you'll need to configure the header location. If you're using an encrypted boot i'd just have them included in the initramfs itself. ugrd isn't really designed to handle luks1 but can be forced to (there is no way to validate luks1 headers reasonably).

I did not completely understand the relation between ugrd and bootloader (grub, in my case). It seems that ugrd handles the initramfs generation, just like genkernel, and it does basically not matter, which bootloader is used to start the initramfs. Is that correct?

Up to now, grub decrypts the luks1 secured BOOT, including kernel and initramfs. So it seems that I could 'just' change genkernel with installkernel and ugrd.
I.e., ugrd needs not to worry about luks1, because grub did this job before ugrd's initramfs is becoming active.

I saw options in ugrd for separated header / keys, so calling luks (luks2) for decrypting the rootfs is maybe just a configuration issue.
Header and keyfile are included in the initramfs.


Is it worth a try this way, or do you see any obstackles in advance?

I'd recommend dropping the encrypted boot stuff, it mostly gets in the way and doesn't really add much if any security (especially when you're having to use luks1 or pbkdf to make it work)

For my setup, I disagree: unencrypted boot means also unencrypted header and keyfile for the root file system, this weakens the system very clearly.

[zen_desu]

https://wiki.gentoo.org/wiki/Rootfs_encryption#UGRD

you can try this

https://github.com/desultory/ugrd/blob/ ... cryptsetup

it should mostly just work for you, but you'll need to configure the header location. If you're using an encrypted boot i'd just have them included in the initramfs itself. ugrd isn't really designed to handle luks1 but can be forced to (there is no way to validate luks1 headers reasonably).

I did not completely understand the relation between ugrd and bootloader (grub, in my case). It seems that ugrd handles the initramfs generation, just like genkernel, and it does basically not matter, which bootloader is used to start the initramfs. Is that correct?

Up to now, grub decrypts the luks1 secured BOOT, including kernel and initramfs. So it seems that I could 'just' change genkernel with installkernel and ugrd.
I.e., ugrd needs not to worry about luks1, because grub did this job before ugrd's initramfs is becoming active.

I saw options in ugrd for separated header / keys, so calling luks (luks2) for decrypting the rootfs is maybe just a configuration issue.
Header and keyfile are included in the initramfs.


Is it worth a try this way, or do you see any obstackles in advance?

I'd recommend dropping the encrypted boot stuff, it mostly gets in the way and doesn't really add much if any security (especially when you're having to use luks1 or pbkdf to make it work)

For my setup, I disagree: unencrypted boot means also unencrypted header and keyfile for the root file system, this weakens the system very clearly.

The headers are essentially already encrypted (at least important data in them is). I mean they have a bit of metadata but keyslots should be protected with a passphrase or similar. In some ways, detaching the header can be a risk because if someone is able to copy them, they could attempt cracking offline. If the headers are not detached, someone would need root privs (or system control) to read them from the drive anyways. If you keep them on /boot and have that regularly mounted, the same sort of threat exists (someone with root can read them).

I'd recommend keeping keyfiles on a USB or something which is ONLY attached during bootup (not your boot partition), and remove that volume when the initramfs has completed (if you are concerned with keys being stolen), but adding another layer of encryption to the keyfiles really doesn't do _that_ much for you. Similarly, if you embed the headers into the initramfs, someone can copy the initramfs and extract them. While you shouldn't let your headers be public data, keyslots secured with argon2 are very secure.

if you're using ugrd, it should do a lot to check that everything included is required. It tries to validate your LUKS headers as well (makes sure you have the right cryptographic backend stuff and kmods), so you'll be warned about issues before rebooting to test. This config should be about what you need to point at keyfiles and header files so they are included and used with your LUKS volume: https://github.com/desultory/ugrd/blob/ ... ml#L86-L94

Concerning bootloader compatibility, ugrd doesn't typically need any kernel cmdline args, so any bootloader should work fine without any extra config.