Bug 2215860

Summary: grub2: Build with baseline ISA flags
Product: Red Hat Enterprise Linux 9 Reporter: Florian Weimer <fweimer>
Component: grub2Assignee: Bootloader engineering team <bootloader-eng-team>
Status: ON_QA --- QA Contact: Release Test Team <release-test-team>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.3CC: mlewando, nfrayer, pjanda
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: grub2-2.06-66.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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 Florian Weimer 2023-06-19 08:51:01 UTC
The grub2 package currently inherits the distribution buildflags for -march= from the distribution defaults. This could cause crashes if the CPU is too old. There are ongoing efforts to improve the diagnostics from the kernel and early userspace, but those won't help if we never get to this point. For -march=x86-64-v2, we seem to be lucky because POPCNT and CMPXCHG16B appeare not be used by GRUB, and the post-SSE2 vector instructions are already avoided by different means.

I suppose something like this would be fairly future-proof:

diff --git a/grub.macros b/grub.macros
index 4a2883d..2d96c1b 100755
--- a/grub.macros
+++ b/grub.macros
@@ -30,6 +30,7 @@
 		-e 's/-fcf-protection//g'			\\\
 		-e 's/-fasynchronous-unwind-tables//g'		\\\
 		-e 's/^/ -fno-strict-aliasing /'		\\\
+		-e 's,-march=x86-64-v[[:alnum:]._-]*,-march=x86-64,g' \\\
 		%{nil}
 
 %global host_cflags %{expand:%%(echo %{build_cflags} %{?_hardening_cflags} | %{cflags_sed})}

It relies on redhat-rpm-config and the GCC defaults to be in sync to some degree (that is, redhat-rpm-config must in inject an -march= flag that can be rewritten if GCC defaults to a non-baseline ISA).

I don't think we use GRUB on s390x, and aarch64 is still at the baseline, so this is the only change that seems to be needed at present. POWER appears to be covered already by other means.

Comment 1 Marta Lewandowska 2023-07-19 15:42:04 UTC
Hi Florian,
Would you be willing to test this once it is built?
Since it's not high priority, it won't happen now, but it will get fixed.

Comment 2 Florian Weimer 2023-07-19 15:47:30 UTC
(In reply to Marta Lewandowska from comment #1)
> Hi Florian,
> Would you be willing to test this once it is built?
> Since it's not high priority, it won't happen now, but it will get fixed.

I can run a build in a RHEL-10-like build environment and inspect the generated assembly using objdump. Is this the kind of testing you expect?

As I wrote in comment 9, in the RHEL 9 build environment, I don't see any non-baseline instructions being generated, so I don't expect any observable change in the chosen instruction set.

Comment 3 Marta Lewandowska 2023-07-19 15:52:37 UTC
(In reply to Florian Weimer from comment #2)
> I can run a build in a RHEL-10-like build environment and inspect the
> generated assembly using objdump. Is this the kind of testing you expect?

That seems reasonable. :)