Created attachment 1713048 [details]
patch which adds the necessary modules

This patch adds the necessary modules. I rebuilt grub with it and I can boot from an encrypted /boot afterwards.

Size increase of grubx64.efi with this patch is 87768 bytes, which I think is negligible on a 600 MB default sized efi system partition.

Created attachment 1729811 [details]
[PATCH] Include in EFI build the modules needed for LUKS support

Thanks for the report and the diff.

The modules needed for LUKS support are already included in Fedora so I took the list of modules from there. The list is more or less what you shared minus some modules that are already pulled as dependencies in current builds.

I also changed the order so they are sorted alphabetically and match how are defined in the Fedora package. I'm attaching the patch for reference.

Hi Javier,

thank you very much for working on this.

Sorry for not sorting the modules in my patch alphabetically, it makes of course more sense to do this.

I just compared the modules that you added to the ones I added and some are missing:

crypto 
gcry_crc
gcry_sha256
pbkdf2

I guess the grub2 version you built is a bit different than the one I used, that could explain the difference.
But it could also be that a module is still missing.

Did you check if you can boot from a /boot that is encrypted with the default luks crypto settings?

I can also offer you that I can do this test if you upload me your rpms somewhere.

Created attachment 1730489 [details]
grub2-efi-x64-2.02-91.el8.x86_64.rpm

You can extract the grubx64.efi from the attached RPM.

I will try to test later today unlocking a LUKS volume but I verified that the missing modules you mentioned are already pulled as dependencies of other modules included.

Thanks for posting the file. I just tried it.

Unfortunately I couldn't boot it, as the gcry_sha256 module seems to be missing. 

gcry_sha512 seems to be included though.

The luks defaults for me (as taken from "cryptsetup --help") are:
LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom

This is what I used and I suggest to make it boot at least with the default values,
also adding sha512 won't hurt of course.

(In reply to Gerd v. Egidy from comment #9)
> Thanks for posting the file. I just tried it.
> 
> Unfortunately I couldn't boot it, as the gcry_sha256 module seems to be
> missing. 
>

Sigh, I meant to include that one explicitly as well since is also
included in the Fedora package but somehow I missed it. The Fedora
package also includes gcry_twofish and gcry_whirlpool, I think it
makes sense to include those too.

Created attachment 1730524 [details]
grub2-efi-x64-2.02-91.el8.x86_64.rpm

Can you please test the new attach RPM instead? It's just a test build so you will need to disable Secure Boot.

Your l(In reply to Javier Martinez Canillas from comment #11)
> Can you please test the new attach RPM instead?

Now it boots, thank you.

> It's just a test build so
> you will need to disable Secure Boot.

I don't expect anything that is not published through the official channels to work with secure boot. I had it disabled for all my tests.

These changes are planned to be included in RHEL 8.4 or is there a chance to get it into an update for 8.3? I'm not too familiar with your processes and criteria for this so I'm asking.

Current plan is to include it in 8.4.
We could try to include it in 8.3, but it depends on consideration why we should make (potentially harmful) change in already tested product. I don't think it is a security update. So there is a chance is, but it isn't high.
Is there any reason why you have to stick with 8.3 after 8.4 is released?

Hello Gerd,

I have a bit issue to verify fix for this bug ...
Can you describe steps needed to fulfil step 
"1. encrypt /boot with luks (you have to do this by hand as anaconda won't let you)"
a bit more in detail, please.

I'm in state that system has either crypted /boot nor can boot, but not both together, which is in contrast with your comment 12

I suppose some modification of grub.cfg is needed as well as I cannot see any command to load crypto modules in the one from installation.

Thank you
Petr Janda

Hi Petr,

sorry, my description was indeed a bit sparse.

Here is a more complete description:

# - fresh install on UEFI hardware or vm
# - custom partitioning selected in anaconda:
#    - automatically created LVM setup
#    - encrypt the LVM
# - boot the machine
# - download the latest RPM attached by Javier
# - force-install the rpm or unpack it and overwrite grubx64.efi in /boot/EFI/redhat with the file from the RPM
# - reboot just to make sure everything is still working 
mkdir /boot-copy
umount /boot/efi
rsync -r -a -H -A -X /boot/ /boot-copy
umount /boot
lsblk
# check the path of /boot, it was /dev/vda2 for me
BOOTPART=/dev/vda2
# type luks1 is crucial here as grub can't yet decrypt luks2
cryptsetup --type=luks1 --force-password luksFormat $BOOTPART
cryptsetup open $BOOTPART cryptedboot
mkfs.ext4 /dev/mapper/cryptedboot
# note down the UUID of the new filesystem
nano /etc/fstab
# change the UUID for /boot to the new one
mount /boot
rsync -r -a -H -A -X /boot-copy/ /boot
mount /boot/efi
cryptsetup luksUUID $BOOTPART
# note down the UUID for the crypted partition
nano /etc/default/grub
# add the UUID for the crypted partition to the kernel cmdline
# prepend it with "rd.luks.uuid=luks-"
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
# check if grub properly picked up the crypted boot
grep cryptomount /boot/efi/EFI/redhat/grub.cfg
reboot
# grub should now ask you for the password
# wait long enough, grub is much slower deriving the crypto key
# the system should boot

About the question if to include it in 8.4 or 8.3:

I think I'll explain my reason for wanting this in a bit more detail,
then you can decide for yourself.

UEFI Secure Boot protects shim, grub, the kernel and any kernel modules.
Encrypting the local partitions protects the rest of the system.
The EFI System Partition has obviously to be left unencrypted, also /boot
unless the changes discussed here are applied.

Since initramfs is on /boot, it is left unprotected.

Anyone with limited physical access (access to disk drives, but no
soldering of firmware flash chips) to a machine can modify initramfs
to make it store the password for disk encryption and later send it to the
attacker through a covert channel. This allows to decrypt the whole
disks.

Encypting /boot protects against this. 

Although aes-xts used in LUKS does not
have a cryptographic protection against modification, it is still good
enough for this purpose. An attacker could modify one block if they new
the exact data that was in it before. But the attacker has no indication
if their guess of the former data was correct. The attacker has only one try in
this scenario, also there is enough randomization on /boot as it is a live
filesystem and also initramfs contains data unique to this installation and
unknown to the attacker like filesystem/LVM UUIDs.

So implementing encryption for /boot allows users to protect their systems
against the attacks outlined here. I don't know if this accounts for a security
update in your criteria.

Having it in 8.3 would mean it is available much faster. I plan to roll out
a few new servers soon where I want to use this. Being able to directly install
on a encrypted /boot (I have an easy to deploy update-image for the installer
that patches anaconda to allow this) would save me the hassle of having to 
encrypt /boot later on when 8.4 is released.

> Is there any reason why you have to stick with 8.3 after 8.4 is released?

Once a new released point version like 8.4 passes internal testing, all existing machines
of this major release are upgraded within a few weeks. I do not run older point
releases.

I'm trying to verify this on nightly compose with grub2-efi-x64-2.02-92.
The grub2-mkconfig adds insmod cryptodisk and sets root='cryptouuid/57ae37...' but doesn't add cryptomount. So after reboot I have to manually decrypt the partition, reload grub configuration and then it can boot.
I don't know if I'm doing something wrong or the mkconfig doesn't work correctly.

The cryptomount option seems to be created by grub2-probe which is part of the grub2-tools package.

I tested it with the procedure written above on CentOS 8.2, which has grub2-tools-2.02-87.

So either the grub2-tools changed in a way that this doesn't work anymore, or there needs to be some yet unknown package installed that was on my system, but not on yours. Or some other yet unknown prerequisite.

Could you retry it with downgrading the whole grub to 2.02-87, but then overwriting the grubx64.efi from the new grub2-efi-x64?

I think that should show if it has to do with something in the newer grub2-tools.

I'd like to offer further help with this, but I guess this nightly compose and it's sources are for Redhat employees only.

I'm changing status to Verified, as grub can now use encrypted /boot. Any usability issues should be fixed when this feature is properly integrated.

Thank you Gerd for detailed steps.

Just for record
I believe that missing cryptomount in grub.cfg is due missing GRUB_ENABLE_CRYPTODISK=y in /etc/default/grub when running grub2-mkconfig.
I also had to run mkinitrd -f /boot/initramfs-`uname -r`.img `uname -r` to update fstab in initrd so systemd is willing to mount /boot

Hi Petr,

good that you got it working too.

You are right, I forgot about the GRUB_ENABLE_CRYPTODISK. This is something my update-image-patch for anaconda adds, among other things like allowing a crypted /boot in anaconda and allowing to drop /boot altogehter.

So I'm adding the source of this patch here, in case someone else later stumbles upon this bugzilla entry.

To use it, build it with the included script, then add it to the installer commandline like this: 
inst.updates=http://your-local-repo-server.example/rhel8/i2n-updates.img

This should allow you to directly create the crypted boot while installing with anaconda.

Created attachment 1737292 [details]
anaconda update-image to allow a crypted /boot

Is there still some info requested from me as the one who opened the bug? Or is the needinfo just some part of a redhat-internal process?

I can just report that I use the grubx64.efi that Javier posted above on a test system with 8.3. It works as expected and I run this system with a fully encrypted /boot.

Hello Gerd,

someone else attached a customer case to this bz and I wanted to ask him something. As there was a change in bug you've got a notification, I set needinfo wrongly, probably. So sorry for that, nothing is needed from you, but thank you for answering and your confirmation.

Petr

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (grub2 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1648