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.
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.
(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.
(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. :)