Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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 1Marta 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.
(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 3Marta 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. :)
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 (grub2 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-2023:6653
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.