Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2124255

Summary:	Allow to install /boot on an encrypted partition
Product:	Red Hat Enterprise Linux 9	Reporter:	Gerd v. Egidy <gerd>
Component:	grub2	Assignee:	Bootloader engineering team <bootloader-eng-team>
Status:	CLOSED MIGRATED	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	9.0	CC:	bootloader-eng-team, jkonecny, jstodola
Target Milestone:	rc	Keywords:	FutureFeature, MigratedToJIRA
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-09-16 17:08:34 UTC	Type:	Story
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gerd v. Egidy 2022-09-05 12:53:10 UTC

Description of problem:

The installer of RHEL9 prevents installing /boot to a encrypted partition.

Version-Release number of selected component (if applicable):

RHEL 9.0

How reproducible: always

Steps to Reproduce:
1. Go to custom partitioning during a manual install of RHEL9
2. Check "Encrypt" for the /boot partition. LUKS Version 1 or 2 doesn't matter
3. Click Update Settings

Actual results:
The error "/boot cannot be encrypted" appears

Expected results:
No error messages, installing works without issue.

Additional info:

------------------

Why is an encrypted /boot important?

UEFI Secure Boot protects shim, grub, the kernel and any kernel modules.
Encrypting the local partitions protects the data of 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 physical access 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 then allows to decrypt the whole
disks.

Encypting /boot protects against this.

------------------

Implementation details:

Removing the block of encrypted /boot from anaconda is one thing, making
encrypted /boot work is another. To test this I removed the check from
anaconda with a patch and tested it on an UEFI system.

Since RHEL 9 grub.cfg is written to the common location /boot/grub2/grub.cfg.
On UEFI a small config loader is written to /boot/efi/EFI/redhat/grub.cfg:

---
search --no-floppy --fs-uuid --set=dev 1f5d833e-ebeb-4756-ae80-52def7dc4cb5
set prefix=($dev)/boot/grub2

export $prefix
configfile $prefix/grub.cfg
---

This config loader is missing the required bits to decrypt the /boot partition.
I extended the file like this:

---
insmod part_gpt
insmod diskfilter
insmod mdraid1x
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_sha256
insmod lvm
insmod ext2
cryptomount -u df102f5b7442417a88628de1d31225e0

search --no-floppy --fs-uuid --set=dev 1f5d833e-ebeb-4756-ae80-52def7dc4cb5
set prefix=($dev)/boot/grub2

export $prefix
configfile $prefix/grub.cfg
---

Then I was able to boot with the encrypted /boot. The UUID given to the
cryptomount command is the same as it is already written to the 
/boot/grub2/grub.cfg file when setting GRUB_ENABLE_CRYPTODISK=y.

Since the necessary additions to /boot/efi/EFI/redhat/grub.cfg don't look
too complicated to me, I think it is reasonable to add support for this to
get the additional protection for the initramfs files.

Comment 1 Jiri Konecny 2022-09-16 08:40:18 UTC

Could please the bootloader team look on this and give us their opinion on the encrypted /boot?

Comment 2 Robbie Harwood 2022-09-16 14:28:08 UTC

Bootloader team is limited capacity and this work would not be a priority for us.  We do care about initramfs tampering, but our preferred solution involves signing it (possibly by packing it with the kernel).

While the proposed grub config changes appear simple, they are not general (hardcoded uuids, etc.), and moreover are doubly in the wrong place - first, they're modifying the stub config and not the actual config, and second they'll be overwritten by future grub2-mkconfig calls.  It also appears to use a module we don't currently ship, and growing that list isn't done lightly.

Comment 3 Gerd v. Egidy 2022-09-16 15:05:15 UTC

> We do care about initramfs tampering, but our preferred solution involves signing it (possibly by packing it with the kernel).

Could you explain in more detail how you plan to do this? 

Currently initramfs is generated individually on each machine, to include things like md and lvm UUIDs and config and hardware dependent kernel modules. This means you can't sign it with the general Redhat secret keys that are used to sign the kernel and which signatures are checked by shim. Do you plan to change to one generic initramfs used on all installations, so you could sign it?

Or do you have a solution based on TPM and measured boot in mind?

I would prefer a solution that does not rely on a TPM because it adds a big block of complexity and risks of data loss, for example when doing a firmware update.

> they are not general (hardcoded uuids, etc.), and moreover are doubly in the wrong place - first, they're modifying the stub config and not the actual config, and second they'll be overwritten by future grub2-mkconfig calls.

/boot/efi/EFI/redhat/grub.cfg would need the hardcoded partition UUID to decrypt, that is correct. But this file already contains the filesystem UUID to search for, so I don't think that adding one more UUID is that much of a change.

Since RHEL 9 grub2-mkconfig does not touch this file anymore, it only writes to /boot/grub2/grub.cfg. So it does not overwrite anything in /boot/efi/EFI/redhat/grub.cfg where my proposed changes would go.

So I don't think these changes are in the wrong place.

> It also appears to use a module we don't currently ship

Which module is missing?

I tested booting with this setup before opening this issue and made the necessary changes manually. It booted fine and I did not miss any module. I did not rebuild the grub EFI module for this.

Comment 4 Robbie Harwood 2022-09-19 18:45:29 UTC

> Since RHEL 9 grub2-mkconfig does not touch this file anymore, it only writes to /boot/grub2/grub.cfg. So it does not overwrite anything in /boot/efi/EFI/redhat/grub.cfg where my proposed changes would go.
>
> So I don't think these changes are in the wrong place.

Well, I do :)

Your message states that "On UEFI a small config loader is written to /boot/efi/EFI/redhat/grub.cfg:", so yes, you are writing to this file.  This file is a minimal stub because fat32 doesn't support symlinks, and anything more doesn't belong in it.

> Which module is missing?

If I recall correctly, diskfilter isn't in the signed set, but I only looked on a superficial level and it might be fine for other reasons.

Comment 5 Gerd v. Egidy 2022-09-19 19:31:16 UTC

/boot/efi/EFI/redhat/grub.cfg is written once, during installation via anaconda. It isn't changed or written to later on. Currently it contains the filesystem UUID of /boot. If /boot were encrypted, it would also contain the cryptomount command with the UUID of the encrypted filesystem. It still needs just to be written once during installation.

So I don't see why this is makes such a difference, it is still just pointing to the actual grub.cfg.

Comment 6 Jiri Konecny 2022-09-30 09:09:03 UTC

Thank you a lot Robbie for your input here. Based on the comment 2 I understand that the bootloader doesn't support this right now.

I'm switching this bug to bootloader team to decide about the level of support. If you agree to have the support please create a clone on Anaconda.

Comment 8 RHEL Program Management 2023-09-16 17:07:47 UTC

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 9 RHEL Program Management 2023-09-16 17:08:34 UTC

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.