Bug in Calamares when using unencrypted boot?


I’ve installed EndavourOS using the September 2020 release. During installation, I’ve created a partition layout with an unencrypted boot partition and an encrypted root partition, as I used to do in other distributions before.

However, through a German blog article on KDE Neon I came across a possible security problem with Calamares, which is said to make encryption completely useless with this partition layout. The problem is said to be the following according to Calamares bug tracker: “the current Calamares code always puts a LUKS keyfile into the initramfs as soon as you enable LUKS encryption, which is why leaving /boot unencrypted in manual partitioning currently defeats the whole purpose of using LUKS”.

Although the bug seems to be be fixed now, the september release was published before this merge request. So was EndavourOS affected by this bug (I’m not sure, therefore I didn’t posted in the bug section)? How do I find out?

And if it’s the case, is there a way to fix this without reinstalling the system?

Thanks in advance!

1 Like

Don’t there is a february release.
Welcome to the forum! :hugs:

I know, but I already installed the system back in October or so and only now read the report on the mentioned bug. I just wanted to know if my encryption is now completely insecure and if I have to reinstall…
Thank you!

Yes, very easily! No need to reinstall.

But before we get to that, so that we don’t mess up your system, could you please post the output of the following commands.

ls /boot
ls /
sudo cat /etc/crypttab | grep -v "#"

sudo cryptsetup luksDump /dev/sdaN | grep Slot
Replace sdaN with your encrypted devices partition (probably sda3 or sda2). Run … blkid | grep crypto_LUKS | cut -d \: -f 1 … to find out which devices are encrypted.

1 Like

This is why I prefer the /boot directory within an encrypted root partition, so kernel and initramfs images cannot be tampered with and potentially “trojan horsed”.

mkinitcpio creates the initramfs, not Calamares, so I assume Calamares provides the necessary settings in /etc/mkinitcpio.conf.

This config setting will add the Calamares created crypto keyfile to a generated initramfs.


This is required for an encrypted /boot partition.

Want the keyfile removed from your unencrypted /boot initramfs images, then just remove it from the mkinitcpio config and regenerate.


You may have to enter your luks password twice though.

1 Like

As @otherbarry described, it’s quite easy removing the keyfile entry. You’ll maybe also want to clean up some other things and remove the unneeded keyfile(s) etc.

But before you address this, could you please provide the data I asked for above. This is for future reference; just to see how calamares set up your system and what really needs to be changed for you to have a secure system.

Oh, and maybe also provide the output of
cat /etc/mkinitcpio.conf | grep FILES

This would surely also be useful for others, so thanks in advance.

$ lsblk
NAME                                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sr0                                         11:0    1  1024M  0 rom   
nvme0n1                                    259:0    0 931,5G  0 disk  
├─nvme0n1p1                                259:1    0   400M  0 part  /boot/efi
├─nvme0n1p2                                259:2    0    16M  0 part  
├─nvme0n1p3                                259:3    0 393,4G  0 part  
├─nvme0n1p4                                259:4    0   600M  0 part  
├─nvme0n1p5                                259:5    0   1,5G  0 part  /boot
└─nvme0n1p6                                259:6    0   500G  0 part  
                                           254:0    0   500G  0 crypt /

$ ls /boot
amd-ucode.img  grub        initramfs-linux.img  vmlinuz-linux
efi            initramfs-linux-fallback.img  lost+found

$ ls /
bin                 dev   lib         mnt   root  srv       tmp
boot                etc   lib64       opt   run   swapfile  usr
crypto_keyfile.bin  home  lost+found  proc  sbin  sys       var

$ sudo cat /etc/crypttab | grep -v "#"

luks-c2001d86-4b65-4248-b1b7-b92940dba0d0 UUID=c2001d86-4b65-4248-b1b7-b92940dba0d0     /crypto_keyfile.bin luks,discard

(the swapfile I created myself)

blkid | grep crypto_LUKS | cut -d \: -f 1 or blkid has no output
(I guess because of my NVMe SSD?)

But blkid -o list list has an output:

$ blkid -o list
device                       fs_type     label        mount point                      UUID
/dev/nvme0n1p1                                        /boot/efi                        
/dev/nvme0n1p2                                        (nicht eingehängt)              
/dev/nvme0n1p3                                        (nicht eingehängt)              
/dev/nvme0n1p4                                        (nicht eingehängt)              
/dev/nvme0n1p5                                        /boot                            
/dev/nvme0n1p6                                        (nicht eingehängt)              

So the output of sudo cryptsetup luksDump /dev/nvme0n1p6 | grep Slot is the following:

Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

The FILE section of /etc/mkinitcpio.conf:

$ cat /etc/mkinitcpio.conf | grep FILES

So I guess that means there is no keyfile in initramfs?


1 Like

Sorry, my fault, should have been :grimacing:
sudo blkid | grep crypto_LUKS | cut -d \: -f 1

As @otherbarry already confirmed you aren’t affected by the vulnerability described in your initial post.

But, there are some unnecessary leftovers from the calamares install you might also want to get rid of.

  1. You don’t need the luks-c[...] /crypto_keyfile.bin [...] line in /etc/crypttab. Just comment or remove it from the file.

  2. Your encrypted partitions (/dev/nvme0n1p6) luks-header contains two passphrases. If you didn’t manually add a second passphrase after installation the keyslot 1 typically holds crypto_keyfile.bin as a passphrase. This was added by calamares but seeing that you don’t need to chain-unlock anything automatically without inputting a passphrase it doesn’t serve any purpose and can be deleted from the luks-header with the following command:
    sudo cryptsetup luksKillSlot /dev/nvme0n1p6 1

  3. You now have no need for /crypto_keyfile.bin and can delete this file.

  4. For good measure, just rebuild with
    sudo mkinitcpio -p linux

You’ll then have a system without any unnecessary passfiles and entries lying about; the way it would have been set up during a manual install.

There is nothing wrong with using keyfiles, why are you recommending the removal of all keyfile configs, keyslots and the file itself?

There are no security issues using keyfiles when the keyfile itself is located within the an encrypted partition.

The issue is the keyfile potentially being accessible within an initramfs file in an unencrypted /boot partition, not the keyfile setup itself.

IMHO Calamares default password + keyfile setup is correct and does not warrant the changes @2000 is recommending.

Sorry @otherbarry, I never stated using keyfiles being “wrong”.
It’s just, in @jonthan’s case, IMO this keyfile and the keyslot it’s taking up serve absolutely no purpose and would never have been used if the encryption would have been set up by hand.

But I’m always willing to learn and change my long established ways if need be. Maybe you could enlighten me, as to why the OP should need that specific keyfile and the keyslot it takes up? And if he doesn’t, why he should keep it?

This is default behavior when using an encrypted /boot, which the OP clearly isn’t. If you’d for example manually install the Arch way with an unencrypted /boot and a single encrypted root partition, you’d never create a useless keyfile (here crypto_keyfile.bin) and add it to one of the keyslots. Real world analogy: Unless you copy that key and store it elsewhere, you’d just have a key lying around in a room you always, and only can, unlock by other means (your initial key =password).

Calamares default password + keyfile setup works with an encrypted and an unencrypted /boot setup, right. But in case of the latter, it doesn’t “hurt” but also doesn’t serve any purpose whatsoever. It’s probably just a shortcut or “lazy” programming (I totally understand that this isn’t a high priority for the developers!) on calamares side.

That’s why, IMHO, I still stand by those recommendations. :grinning_face_with_smiling_eyes:

Just two questions on this, although it may be little bit off-topic. I followed your HOWTO, but I chose a separate unencrypted boot partition. So, as far as I understood, I can delete the entry in /etc/crypttab and delete the /crypto_keyfile.bin and emtpy the key slot. If I do not empty the key slot, would this be a problem here since I don’t want to kill the wrong key slot? Second, is this

missing in the HOWTO?

No, you’ll just have “a door with a second keyhole, for that you don’t have a key” :grin: . If you don’t empty the keyslot it will just take up space and reduce the available keyslots by one. But it’s no problem if you don’t remove the key.

BTW, if you haven’t added any keys manually, calamares always sets up two keys; your initial unlock password in keyslot 0 and the keyfile (/crypto_keyfile.bin) in slot 1. In this case it is perfectly safe to remove keyslot 1.

No, I don’t think so, because calamares usually sets that up right during install there’s no need to add or remove this manually. But I’ll maybe take some time to check if this still is the case.

1 Like

So this is expected to be missing if using an unecrypted /boot, correct?


1 Like

Technically the only use case that should not require a keyfile is an unecrypted /boot with a single encrypted root partition. Which Calamares requires to be manually partitioned.

All other scenarios should use a keyfile.

Encypted /boot requires a keyfile.

Unencrypted /boot with multiple encrypted partitions (ie root + swap, or root + home, or root + home + swap, etc) should use a keyfile. Otherwise the password is required to be typed once per partition each boot.

It does no harm leaving the keyfile config and keyfile there as it may be needed later if an additional luks partition is added manually (ie swap or home or data or pacman cache or …).

Wouldn’t call it lazy not catering for the one manual partitioning variant that technically does not require a keyfile.

Removing the keyfile config in this instance is simply not needed, and creates unnecessary risk.