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 1654202 - Tboot not testable anymore on RHEL8.0 due to grub2 EFI modules removed multiboot support
Summary: Tboot not testable anymore on RHEL8.0 due to grub2 EFI modules removed multib...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: tboot
Version: 8.0
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Tony Camuso
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 1481907 1916359
TreeView+ depends on / blocked
 
Reported: 2018-11-28 09:04 UTC by Yunying Sun
Modified: 2021-04-15 13:28 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-03 13:19:15 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Yunying Sun 2018-11-28 09:04:59 UTC 
During tboot validation, we used to use script below to create customized grubx64.efi：
GRUB_MODULES="all_video boot btrfs cat chain configfile echo efifwsetup \
efinet ext2 fat font gfxmenu gfxterm gzio halt hfsplus iso9660 \
jpeg loadenv lvm mdraid09 mdraid1x minicmd normal part_apple \
part_msdos part_gpt password_pbkdf2 png reboot search \
search_fs_uuid search_fs_file search_label sleep syslinuxcfg \
test tftp regexp video xfs linuxefi multiboot multiboot2"
grub2-mkimage -O x86_64-efi -o grubx64.efi.new -p /EFI/fedora $GRUB_MODULES

With grub2-efi-x64-modules installed, this script works for Fedora 28 & RHEL7.x, but it does not work anymore on Fedora 29 & RHEL8.0, with errors showing not able to find modules like linuxefi.mod/multiboot2.mod/multiboot.mod under /usr/lib/grub/x86_64-efi/.

Grub2-efi-x64-modules for Fedora 28 is at version 2.02-34, while it’s currently at 2.02-62 for Fedora 29.

Why multiboot* modules are not available anymore under /usr/lib/grub/x86_64? Here are comments from grub2-efi module maintainer javierm:
"Yes, it's expected. The multiboot{,2} modules aren't built for EFI anymore since commit 1295c2dffe42 ("Disable multiboot, multiboot2, and linux16 modules on EFI
builds.") [0].

The reason why we don't build the EFI binary with these modules is that with them an attacker could bypass the Secure Boot mechanism and execute unsigned binaries, for more information take a look to CVE-2015-5281 [1].

[0]: https://github.com/rhboot/grub2/commit/1295c2dffe42
[1]: https://nvd.nist.gov/vuln/detail/CVE-2015-5281"


This ticket is created for users and Red Hat to be aware of this issue.
Comment 1 Tony Camuso 2018-11-28 15:28:05 UTC 
Given that this situation is not likely to change, I'm disposed to close this bug as DEFERRED.

Any objections? Comments?
Comment 2 Yunying Sun 2018-11-29 01:12:32 UTC 
No objections to close this.

Just for the record: Intel will eventually move from tboot to tboot.efi in 2019, then tboot will not rely on grub.
Comment 3 Tony Camuso 2018-12-03 13:19:15 UTC 
I'm closing this as deferred, rather than wontfix.

With intel migrating tboot to tboot.efi, the security issues with tboot on efi systems should be fixed.
Comment 4 Pragyan Pathi 2019-01-04 18:48:36 UTC 
(In reply to Tony Camuso from comment #3)
> I'm closing this as deferred, rather than wontfix.
> 
> With intel migrating tboot to tboot.efi, the security issues with tboot on
> efi systems should be fixed.

Tony
We will need Red Hat to somehow document this issue for customers. Is there a docbase associated with this issue.
Thank you
Comment 5 Tony Camuso 2019-01-14 20:06:17 UTC 
(In reply to Pragyan Pathi from comment #4)
> (In reply to Tony Camuso from comment #3)
> > I'm closing this as deferred, rather than wontfix.
> > 
> > With intel migrating tboot to tboot.efi, the security issues with tboot on
> > efi systems should be fixed.
> 
> Tony
> We will need Red Hat to somehow document this issue for customers. Is there
> a docbase associated with this issue.
> Thank you

Yes, please see the following Advisory.

https://access.redhat.com/articles/2217041
Comment 6 Steven Haigh 2020-01-29 07:17:19 UTC 
So as this is an old BZ, but probably the most relevant, disabling multiboot stops the ability to be able to boot Xen on UEFI hardware.

This means until multiboot2 is restored, you cannot use Xen on systems that are UEFI native.

Given the attack vector for this is "User has a console or root access", is breaking multiple other systems warranted?
Comment 7 Javier Martinez Canillas 2020-01-29 08:10:20 UTC 
There is a new bug filed for this issue as Bug #1779480, and it was decided there that this will be fixed.

The multiboot* won't be built into the GRUB efi binary so won't be usable with Secure Boot enabled, but they will be built for efi so would be usable with Secure Boot disabled.
Comment 8 Steven Haigh 2020-01-29 08:38:14 UTC 
Ah - that's not public so I couldn't find it. Any chance of being added to the Cc to allow me to monitor?
Comment 9 Tony Camuso 2020-08-28 13:52:31 UTC 
(In reply to Steven Haigh from comment #8)
> Ah - that's not public so I couldn't find it. Any chance of being added to
> the Cc to allow me to monitor?

While we could not add you to the BZ, as the reporter filed it as "private", I can inform you that as of this morning, Aug 27, 2020, the problem has been fixed in RHEL-8.3.0, which has grub2 2.02-84.
Comment 10 Tony Camuso 2021-04-15 13:28:18 UTC 
*** Bug 1920396 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.