FS#69624 - [glibc] Bug causes failure in most binaries leading to massive failure system wide

Attached to Project: Arch Linux
Opened by Sp1d3rmxn (sp1d3rmxn) - Friday, 12 February 2021, 13:27 GMT
Last edited by Allan McRae (Allan) - Sunday, 14 February 2021, 10:25 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

glibc critical bug shuts down all commands with an error:

-> /usr/lib/libc.so.6: CPU ISA level is lower than required


Additional info:
Bug was known about since 2-3-21, arch package was created 2-6-21 fix appears to be available since 2-8-21

report: https://sourceware.org/bugzilla/show_bug.cgi?id=27318

patch(es): https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-libs/glibc?id=5dbd6a821ff753e3b41324c4fb7c58cf65eeea33
and https://lists.openembedded.org/g/openembedded-core/topic/patch_glibc_require_full/80368976?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,80368976

Steps to reproduce:
1. upgrade
2. run any command "ls" or "dmesg" immediately you get the -> /usr/lib/libc.so.6: CPU ISA level is lower than required <-

Without doing this as part of the upgrade you will be accused of doing a "partial upgrade", would like to do a proper upgrade that continues to lead to a proper running system.
This task depends upon

Closed by  Allan McRae (Allan)
Sunday, 14 February 2021, 10:25 GMT
Reason for closing:  None
Additional comments about closing:  Original submitter banned, so can not get more info. No-one else reporting issue.
Comment by Doug Newgard (Scimmia) - Friday, 12 February 2021, 13:29 GMT
What machine is this on? Your other ticket mentioned i686 and i486, neither of which Arch supports.
Comment by Sp1d3rmxn (sp1d3rmxn) - Friday, 12 February 2021, 13:36 GMT
x86_64.

Last ticket was accidental copy/paste.

Edit:
This is on machine running the latest x84_64 archlinux distro. I am not sure how much more I can answer the question because whether you like it or not the first ticket was an accidental copy/paste.
Comment by Sp1d3rmxn (sp1d3rmxn) - Friday, 12 February 2021, 13:37 GMT
Also in the bug reports and patches they are for x86_64 but, you probably saw that already leading you to ask the clarification.
Comment by Doug Newgard (Scimmia) - Friday, 12 February 2021, 13:38 GMT
That doesn't answer the question, though.
Comment by Sp1d3rmxn (sp1d3rmxn) - Friday, 12 February 2021, 13:39 GMT
The upstream patches work from what I can tell. However in maintaining things properly it would be prudent to have them added to prevent improper upgrading, in addition others would probably appreciate not dealing with this bug as it really messes things up quickly.
Comment by Sp1d3rmxn (sp1d3rmxn) - Friday, 12 February 2021, 13:40 GMT
Comment by Doug Newgard (Scimmia) - Friday, 12 February 2021, 13:49 GMT
So you come in acting like a complete asshole making all kinds of accusations, and this isn't the first time, then you refuse to answer a simple question about the hardware you're using? Care to give me a reason I shouldn't just ban you?
Comment by Sp1d3rmxn (sp1d3rmxn) - Friday, 12 February 2021, 14:00 GMT
Whatever man grow the fuck up.
Comment by Doug Newgard (Scimmia) - Friday, 12 February 2021, 14:03 GMT
OP has been banned, but from the tickets, it looks like this might be happening on SandyBridge? No idea, but it does appear that it might be valid.
Comment by Eli Schwartz (eschwartz) - Friday, 12 February 2021, 14:35 GMT
From a quick perusal of libc-alpha it seems like this might only be a problem iff you compile your own glibc and use -march= for some CPU that falls halfway between two ISA markers.

Then, glibc gets compiled for the lower ISA marker "plus a bit more that this cpu supports", but gets tagged for the next ISA level up despite the intended cpu target not fully supporting or declaring support for that level.

Hence why the upstream reporter was reporting from gentoo; on gentoo, it's routine to compile your own glibc instead of using a distro one compiled for -march=x86-64
Comment by Andreas Baumann (andreas_baumann) - Friday, 12 February 2021, 15:11 GMT
In Archlinux32 we had this issue because we are fiddling with --march for i486, i686 and pentium4.

We went with the Gentoo approach and just disabled the ISA-detection completely:

# https://lwn.net/Articles/845329/, ISA-Level breakage in glibc 2.33
# disabling all ISA level guessing for now (see https://bugs.archlinux32.org/index.php?do=details&task_id=145&status[0]=)
eval "$(
declare -f build | \
sed '
s|--prefix=/usr|--prefix=/usr libc_cv_include_x86_isa_level=no|g
'
)"

If you fiddle with --march, you are on your own basically.. :-)

I cannot imagine that guessing ISA levels is wrong for 64-bit or anything
remotely modern, so I think the bug doesn't belong here..
Comment by Allan McRae (Allan) - Friday, 12 February 2021, 20:55 GMT
readelf -a /usr/lib/libc.so.6 | grep ISA
x86 ISA needed: x86-64-baseline
x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4

Looks like we need the lowest level of x86-64, as expected. However, we do provide the multi-arch binary. Unless cpu detection is failing at runtime (which is different from the linked bugs and patches), we don't have a bug here.

Without more details, I think this can be closed.
Comment by Toolybird (Toolybird) - Friday, 12 February 2021, 21:41 GMT
> a problem iff you compile your own glibc and use -march=

Yes.

> If you fiddle with --march, you are on your own basically.. :-)

For sure.

> we don't have a bug here

Agreed. Definitely an upstream glibc issue.

Related:

https://bbs.archlinux.org/viewtopic.php?id=263371

Loading...