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
TreeView+ depends on / blocked
 
Reported: 2018-11-28 09:04 UTC by Yunying Sun
Modified: 2020-01-29 08:38 UTC (History)
9 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:


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@redhat.com:
"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?


Note You need to log in before you can comment on or make changes to this bug.