Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1415032 - dracut-fips does not check the path in BOOT_IMAGE for .hmac
dracut-fips does not check the path in BOOT_IMAGE for .hmac
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dracut (Show other bugs)
7.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Lukáš Nykrýn
Release Test Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-01-19 21:11 EST by Ryan Barry
Modified: 2018-04-10 14:10 EDT (History)
9 users (show)

See Also:
Fixed In Version: dracut-033-534.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-10 14:07:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0964 None None None 2018-04-10 14:10 EDT

  None (edit)
Description Ryan Barry 2017-01-19 21:11:01 EST
Description of problem:
dracut-fips does not check BOOT_IMAGE carefully, and assumes .vmlinuz*.hmac will always be found in /boot, even when BOOT_IMAGE specifies a kernel in a subdirectory.

Version-Release number of selected component (if applicable):
dracut-fips-033-463.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Put vmlinuz, initramfs, System.map, and .vmlinuz*.hmac in a subdirectory of /boot
2. Try to boot with fips=1

Actual results:
dracut-fips cannot find .vmlinuz*.hmac

Expected results:
BOOT_IMAGE supports booting from subdirectories, so dracut-fips should do the same.
Comment 3 Jan Stodola 2017-02-07 04:38:54 EST
Harald, Lukáš,
the patch would probably break booting on s390x, since BOOT_IMAGE there doesn't contain the path to the kernel image - it identifies the number of the boot record that was selected in the bootloader, for example:

[root@rtt7 ~]# cat /proc/cmdline 
root=/dev/mapper/rhel_rtt7-root crashkernel=auto rd.dasd=0.0.3227 rd.dasd=0.0.3427 rd.dasd=0.0.3727 rd.dasd=0.0.3027 rd.dasd=0.0.3527 rd.dasd=0.0.3327 rd.dasd=0.0.3127 rd.dasd=0.0.3627 rd.lvm.lv=rhel_rtt7/root rd.lvm.lv=rhel_rtt7/swap cio_ignore=all,!condev rd.znet=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0,portname=FOOBAR BOOT_IMAGE=2
[root@rtt7 ~]#
Comment 4 Harald Hoyer 2017-06-29 04:41:09 EDT
(In reply to Jan Stodola from comment #3)
> Harald, Lukáš,
> the patch would probably break booting on s390x, since BOOT_IMAGE there
> doesn't contain the path to the kernel image - it identifies the number of
> the boot record that was selected in the bootloader, for example:
> 
> [root@rtt7 ~]# cat /proc/cmdline 
> root=/dev/mapper/rhel_rtt7-root crashkernel=auto rd.dasd=0.0.3227
> rd.dasd=0.0.3427 rd.dasd=0.0.3727 rd.dasd=0.0.3027 rd.dasd=0.0.3527
> rd.dasd=0.0.3327 rd.dasd=0.0.3127 rd.dasd=0.0.3627 rd.lvm.lv=rhel_rtt7/root
> rd.lvm.lv=rhel_rtt7/swap cio_ignore=all,!condev
> rd.znet=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0,portname=FOOBAR
> BOOT_IMAGE=2
> [root@rtt7 ~]#

https://github.com/dracutdevs/dracut/commit/3d875f77f3d1c5e4161794ca59025bc6bcd77eaa
Comment 18 Jakub Vavra 2018-02-23 09:02:25 EST
Due to internal working of booting on s390x this fix does not work there because BOOT_IMAGE is not populated with the expected strings but a number instead.
On x86_64 the patch works as expected.
On s390x is the normal boot with everything in /boot unaffected but moving kernel, initrd and hmac into subdirectory results in broken boot as the hmac is still expected directly in /boot.

I am marking this as VERIFIED.
Comment 21 errata-xmlrpc 2018-04-10 14:07:53 EDT
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, 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-2018:0964

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