Bug 1784473

Summary:	fips-mode-setup breaks the Grub default value handling
Product:	Red Hat Enterprise Linux 8	Reporter:	Renaud Métrich <rmetrich>
Component:	crypto-policies	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED ERRATA	QA Contact:	Ondrej Moriš <omoris>
Severity:	high	Docs Contact:
Priority:	high
Version:	8.1	CC:	bootloader-eng-team, cbesson, fmartine, hkario, nmavrogi, omoris, tmraz
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.3
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	crypto-policies-20200527-1.git0a29b28.el8	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-04 01:58:27 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Renaud Métrich 2019-12-17 14:31:27 UTC

Description of problem:

Initially, before running fips-mode-setup at all, BLS entries's "options" line looks like the one below:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
options $kernelopts $tuned_params
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This enables Grub to work just fine when changing the GRUB_CMDLINE_LINUX line in /etc/default/grub and running grub2-mkconfig, because $kernelopts in /boot/grub2/grubenv is adjusted.

Unfortunately, everything starts breaking after executing "fips-mode-setup --enable".
This leads to "options" line to become STATIC, as shown below:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
options root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap console=tty0 console=ttyS0,115200n8 $tuned_params fips=0 boot=UUID=17c2c80a-afad-4b64-a31b-55b21ced3740
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Hence, further modification of GRUB_CMDLINE_LINUX line in /etc/default/grub is not taken into account anymore, because $kernelopts in /boot/grub2/grubenv is adjusted *but* $kernelopts is now ignored.
Same happens for $tuned_params.

Note that "fips-mode-setup --disable" doesn't help here because it doesn't restore the entry, just changes "fips=1" to "fip0".


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

crypto-policies-20190807-1.git9b1477b.el8.noarch


How reproducible:

Always


Steps to Reproduce:
1. Execute "fips-mode-setup --enable"
2. Check BLS entries content

Actual results:

Broken "options" line


Expected results:

Something like "options $kernelopts $tuned_params $fips" and a new "fips" variable in /boot/grub2/grubenv managed by fips-mode-setup.
Or /etc/default/grub updated accordingly, appending "fips=1 boot=..."

Comment 1 Tomas Mraz 2019-12-17 16:02:24 UTC

Why cannot grubby DTRT on BLS enabled system and just modify kernelopts? It is a huge mess and I would really like to know from some expert what should fips-mode-setup do to modify the kernel options without breaking any relevant use-cases.

Comment 2 Javier Martinez Canillas 2020-01-14 14:18:43 UTC

(In reply to Tomas Mraz from comment #1)
> Why cannot grubby DTRT on BLS enabled system and just modify kernelopts? It

That's what it does when using the grubby --update-kernel=ALL option.

> is a huge mess and I would really like to know from some expert what should
> fips-mode-setup do to modify the kernel options without breaking any
> relevant use-cases.

I've looked at the fips-mode-setup script and I see that's running 'grubby --update-kernel=$default_kernel --args="$fipsopts"' and then 'grub2-editenv - set kernelopts="$kernelopts $fipsopts"'. Since the intention seems to be to update the cmdline for all the entries, I think that instead it should run 'grubby --update-kernel=ALL --args="$fipsopts"'.

With that command grubby will update the $kernelopts variable. The reason why the 'grubby --update-kernel=$kernel --args=$foo' expands the $kernelopts variable and writes the resulting value in the BLS snippet for $kernel is that the user is telling grubby that only wants to modify the cmdline for that entry. So the $kernelopts variable can't be updated since that will affect all the entries.

That's why grubby supports an ALL argument for the --update-kernel option to specify that all the entries should modified, so grubby updates the $kernelopts variable instead of editing the options fields in the BLS files.

Comment 3 Tomas Mraz 2020-01-14 14:37:40 UTC

Do I get it right that grubby --update-kernel=ALL --args="$fipsopts" would replace both the existing grubby call and the grub2-editenv call?

Comment 4 Javier Martinez Canillas 2020-01-14 14:45:45 UTC

(In reply to Tomas Mraz from comment #3)
> Do I get it right that grubby --update-kernel=ALL --args="$fipsopts" would
> replace both the existing grubby call and the grub2-editenv call?

That's correct.

Comment 5 Tomas Mraz 2020-01-14 15:01:10 UTC

OK, thank you. Reassigned back to crypto-policies.

Comment 12 errata-xmlrpc 2020-11-04 01:58:27 UTC

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 (crypto-policies 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-2020:4536