Re: [PATCH v2] x86: Require full ISA support for x86-64 level marker [BZ #27318]

[Nix <nix@esperi.org.uk>]

On 4 Feb 2021, Andreas K. Hüttel via Libc-alpha outgrape:
> Also, is Sandy Bridge the only case where this happens?

Definitely not. Thank goodness I spotted this thread: I just nearly
wrecked my (32-bit) AMD Geode firewall (built with -march=geode)
installing 2.33, because it is showing up with this totally wrong
ABI-needed stamp:

Displaying notes found in: .note.gnu.property
  Owner                Data size 	Description
  GNU                  0x0000000c	NT_GNU_PROPERTY_TYPE_0
      Properties: x86 ISA needed: x86-64-v2

merely because it is built on a Broadwell CPU (Geodes are a bit too slow
to build glibc these days, and also this Geode has no compiler
installed). (My GCC is GCC 10.2 built with -march=native, but obviously
the -march=geode used at glibc compilation time usually overrides this
perfectly well and glibc works fine.)

It seems to me that this brings back the same problem we used to have
with the --enable-kernel option, where specifying a minimum kernel
version that was too high would lead to all binaries failing to execute,
only worse: if you *do* upgrade and not keep the old shared libraries
around to sln to (and don't have a statically-linked busybox shell or
something to recover), you can't recover by merely starting a suitable
kernel: you have to *physically upgrade the processor*, which is
probably impossible. (Or boot off an emergency rescue disk or something,
and recover from there). This despite the fact that a 32-bit x86 glibc
is not going to be using any of the (by definition x86-64-specific)
facilities that the ISA level is checking for, so it's not even
preventing execution for a good reason! (We don't even use SSE math on
x86-32, do we?)

Worse yet, because this is looking at the CPU ID, tests in a compilation
container are going to pass: even tests in a virtual machine will
probably pass, only to fail disastrously as soon as you install on the
real hardware.