LUKS2 support in OMLx installation (GH issue #3083)

[sigvirt]

Hi,

Sometime back one of the users had requested support for installing OpenMandriva on LUKS2. It is closed now due to inactivity (30 day limit). This topic lead to GH issue #3083. I use encryption (on family PC), although had no idea about luks1 vs luks2. I am interested in this issue and for couple days now trying to get it to work. However, I felt my comments on GH looked more like journal entries of my troubleshooting than good GH comment. So I am raising this topic here to discuss any t/s or for possible long form discussion.

For the sake of completeness, currently on OM,

• Automated encrypted install works (both ‘Replace a partition’ and ‘Erase disk’ options; we have to select ‘Encrypt system’ option)
• Manual encrypted install works (both single partition as well as separate unencrypted /boot + encrypted system partition cases; we have to select ‘Encrypt’ checkbox at the right page)

So, as such there is no issue. However, the LUKS version used is luks1.

The OP from linked topic wanted luks2 option. It is not supported in OM mostly because it is not supported upstream (GRUB) with GRUB2 having limited support for luks2 (only pbkdf2 is supported whereas default algorithm for luks2 is argon2id).

In the issue, @zeroability had linked a calamares option to enable luks2. This was to add luksGeneration: luks2 in the file /etc/calamares/modules/partition.conf. This works in the sense cryptsetup will now use luks2 and the installer completes without failure. However, when we reboot, grub fails to unlock the (correct) passphrase. This is because grub does not handle the default ‘argon2id’ algorithm.

I tried converting this after installation from argon2id to pbkdf2 (with cryptsetup luksConvertKey /dev/sda4 --pbkdf pbkdf2) and then regenerating grubx64.efi, initrd and grub.cfg but inspite of this grub fails to decrypt the partition.

However, we can use luks2, if we also use an unencrypted /boot partition. In this case it is not grub, but initrd which decrypts (with a nice GUI). This can be a manual partitioning scheme or as Lubuntu has done it, a setting in the /etc/calamares/modules/partition.conf file so that it is easy on users. Their file reads like below.

enableLuksAutomatedPartitioning: true
luksGeneration: luks2
partitionLayout:
    - name: "lubuntu_boot"
      filesystem: ext4
      noEncrypt: true
      onlyPresentWithEncryption: true
      mountPoint: "/boot"
      size: 4G
    - name: "lubuntu_2504"
      filesystem: unknown
      mountPoint: "/"
      size: 100%

This creates a /boot partition of 4G (rest for ‘/’), only if we choose to encrypt but otherwise a single ‘/’ partition. With this setup, both ‘Replace a partition’ and ‘Erase disk’ options with ‘Encrypt system’ checked, will result in a working luks2 encrypted install.

So, if we choose to enable luks2 in the installer, we should either,
a) also have custom partition layout like above (probably correct approach), or
b) make sure users refer to @ben79’s article of How to install OMLx with encrypted / and /home . This is difficult to ensure (especially not before users try installation first).

Now, while working on this I came to know there is a patch to add Argon2 support approved upstream (GRUB). However, I did not have success using it. I failed first at patching it (build was failing giving error, “7 out of 7 hunks ignored”). I tried creating a 2.14-rc1 package. This also failed somewhere around applying omv configuration patch. I then built grub2 from source (on live CD). It installs OK but fails to decrypt after install. Not sure what I missed.

Hopefully when grub-2.14 finally lands in OMLx, this issue will be solved (properly without any hacks).

P.S.: @Anon0233, if you are still around and interested, please test the lubuntu hack mentioned above and give feedback.

[SomeDudeInAZ]

Now that I’m back home.

Since I’ve been mucking around with this for the past week…

First off the crypsetup/dm-crypt wiki and especially FAQ is a great resource:

Home · Wiki · cryptsetup / cryptsetup · GitLab

The Arch Wiki also has plenty of good info…

dm-crypt/System configuration - ArchWiki

Generally speaking for LUKS:

• EFI partition: unencrypted
• Boot: unencrypted
• Root: encrypted
• Home: encrypted

Over on the FAQ there is a great discussion over the benefits (or lack thereof) of LUKS for boot, root, and home.

As far as the devs are concerned, it doesn’t make sense to do any of it. Put all your data on a separate data partition/drive and don’t keep anything in home.

Swap is interesting, but here in OM we use zram - since the swap is in ram it’s gone with a reboot - better than luks. You can do the same for /tmp. The only one you can’t do that for is /var/tmp.

Depending on threat model, you could symlink each user’s home dir over onto entirely separate drives/partitions. Even use luks formatted USB drives (nvme in an enclosure maybe?)

All of that being said, from what I can find, luks2 and grub just don’t really mix:

• https://savannah.gnu.org/bugs/?55093
• GitHub - dmoulding/grub-luks2-install: Install GRUB with LUKS2 support
• dm-crypt/Encrypting an entire system - ArchWiki
• Full disk encryption, including /boot: Unlocking LUKS devices from GRUB

Indeed. on that arch wiki page they have a warning (Section 8.1):

“GRUB’s support for LUKS2 is limited; see GRUB#Encrypted /boot for details. Use LUKS2 with PBKDF2 (cryptsetup luksFormat --pbkdf pbkdf2) for partitions that GRUB will need to unlock.”

Of course:

• Libreboot – Encrypted /boot/ on LUKSv2 now possible in Libreboot GRUB (PHC argon2 imported)
• Encrypted /boot via LUKS2 with argon2id – Unofficial (Simplified) Libreboot Documentation
• How is Fedora booting from a LUKS2 partition with argon2id PBKDF when GRUB2 allegedly doesn't support it? - Fedora Discussion
• https://www.reddit.com/r/archlinux/comments/12xcxu3/confused_about_grub_and_luks2/
• Enable LUKS2 and Argon2 support for Grub in Manjaro/Arch | Ming Di Leom's Blog
• Enable LUKS2 and Argon2 support for Grub in Manjaro/Arch | Ming Di Leom's Blog

I have not yet had the chance to test or experiment with any of the above. Though it’s on my to-do list.

I also remember reading (somewhere) where the dmcrypt folks were discussing various crypt considerations - all related to the threat model. Since you can’t really hide a luks partition, ssds, trim support, etc. Naturally, that is the set of bookmarks I can’t find

[zeroability]

@sigvirt

P.S.: @Anon0233, if you are still around and interested, please test the lubuntu hack mentioned above and give feedback.

That is what happens when a user account is deleted.

[sigvirt]

@sigvirt

I then built grub2 from source (on live CD). It installs OK but fails to decrypt after install. Not sure what I missed.

Probably brain? and also a pair of nuts?? How does a package compiled on live CD persists inside installed system?

This time around I chrooted into installed system (OM Cooker with luks2 encrypted ‘/’, single partition). Compiled grub 2.14-rc1. And now decryption at grub level works. So, we just have to wait for version 2.14 (or 2.14-rc1) to be available in our repos.

[zeroability]

Thank you for confirming that. After UM we can look at more things to resolve. I am not sure if we can bring in a RC of grub given how things went the last time we tried to make this option available (a lot of systems that wouldn’t boot at all). I think they would like to see more testing with results like this.

[sez11a (Rich Sezov)]

@sigvirt

And now decryption at grub level works.

Is it super-slow? On my encrypted system, Grub takes forever to decrypt the partition so it can then load and boot. In my testing, if I installed a system with decrypted /boot and /boot/efi, but encrypted / and /home, Grub doesn’t do the decryption and it happens fast.

[sigvirt]

Yes, grub decryption is slow. It is not exact measurement but it probably took 18-20s for the “Slot 0 opened” message to appear. With initrd decryption (on my other PC) it is less than 5s. I am not sure if size of the drive and overall PC specs matter.