v6.4.9 and v6.4.10 causes coredump with lightdm-webkit2-greeter

[CodingCellist]

Description

When using linux-hardened version 6.4.9 or 6.4.10 with lightdm and its webkit2-based greeter, the greeter will continually coredump and attempt to restart, rendering login impossible (tty-switching is not possible as each restart returns the user to the greeter's tty). The culprit seems to be a removed/missing part of libatomic: host-config.h (see attached logs and coredump).

As far as I can tell, downgrading linux-hardened to version 6.4.7 is the only fix; downgrading the other packages involved did not resolve the issue.

Logs + coredump

(note: I believe I cut the logs to the relevant parts, please let me know if not.)

coredump-lightdm-webkit2-greeter.txt
lhardened-6.4.7-works-lightdm-webkit2-greeter.log
lhardened-6.4.9-breaks-lightdm-webkit2-greeter.log
lhardened-6.4.10-breaks-lightdm-webkit2-greeter.log

I'm happy to provide more info if need be : )

System

• Distro: Arch Linux
• lightdm: 1:1.32.0-4
• lightdm-webkit2-greeter: 2.2.5-7
• webkit2gtk: 2.40.5-1
• systemd: 254.1-1

[CodingCellist]

(cross-posted to Arch's bugtracker: https://bugs.archlinux.org/task/79444)

I think a similar issue goes for me too. When I tried to launch a Firefox-based browser, it fails with invalid instruction errors. I have tried debugging the browser and find that the SIMD instructions are failing somehow. I'll provide more info if it's requested.

[ShellCode33]

It seems that I'm also impacted by this, but using npm :

Core was generated by `npm search test              '.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x0000605eb83d7152 in base64_stream_encode_avx2 () from /usr/bin/../lib/libnode.so.115
[Current thread is 1 (Thread 0x605eb6d01f40 (LWP 5765))]
(gdb) bt
#0  0x0000605eb83d7152 in base64_stream_encode_avx2 () from /usr/bin/../lib/libnode.so.115
#1  0x0000605eb81d3e26 in base64_encode () from /usr/bin/../lib/libnode.so.115
#2  0x0000605eb80eb234 in node::StringBytes::Encode(v8::Isolate*, char const*, unsigned long, node::encoding, v8::Local<v8::Value>*) () from /usr/bin/../lib/libnode.so.115
#3  0x0000605eb8186aac in node::crypto::Hash::HashDigest(v8::FunctionCallbackInfo<v8::Value> const&) () from /usr/bin/../lib/libnode.so.115

As the name of the function implies, it seems to be AVX related as well.

dmesg outputs the following:

[ 1157.618115] traps: npm search test[5765] trap invalid opcode ip:605eb83d7152 sp:73a0aeeec658 error:0 in libnode.so.115[605eb7c1c000+2111000]

$ uname -r
6.5.8-hardened1-1-hardened

[hardfalcon]

Potentially related: https://github.com/google/security-research/tree/master/pocs/cpus/xgetbv

[hardfalcon]

Found the culprit: aklomp/base64#121

[CodingCellist]

@hardfalcon, in case it's still relevant, here's my CPU info:

Vendor ID:               GenuineIntel
  Model name:            Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
    CPU family:          6
    Model:               158
[...]
Vulnerabilities:
  Gather data sampling:  Vulnerable: No microcode

[hardfalcon]

@CodingCellist:

  Model name:            Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz

I have a laptop with the exact same CPU model, and the gather data sampling vulnerability can be mitigated on that CPU by a microcode update, whilst still leaving AVX/AVX2 support enabled. My advice would be the following two things:

• check for a BIOS update from your laptop vendor and install it if available,
• install the intel-ucode package, reconfigure your boot loader to additionally load the intel-ucode.img initrd before any other initrd images, and reboot (do this even if your laptop vendor still provides BIOS updates, because hardware vendors have a tendency to be sluggish with integrating microcode updates and other security fixes into their BIOS and releasing BIOS updates)

With a current microcode update version 0xf4, your CPU can do AVX and AVX2 whilst still mitigating the GDS vulnerability.

AFAIK, basically the only CPUs that are affected by the GDS vulnerability but did not receive microcode updates from Intel were some (but not all!) Skylake CPUs. For example, I have an affected machine with a Xeon E3-1270 v5 for which Intel can't be bothered to release microcode updates anymore. A list of CPUs affected by the GDS vulnerability can be found here, and a list of CPUs for which Intel doesn't provide any support anymore can be found here.

[CodingCellist]

@hardfalcon I considered a microcode update, but didn't know if it was worth keeping the laptop in its current state to be able to test patches? IIRC the BIOS+µcode update for my laptop (somewhat understandably) locks the version to that one and newer once applied. Then again, who knows how long it'll take before those land...

[hardfalcon]

The microcode updates from the intel-ucode and amd-ucode packages are not permanent, but are only loaded into the CPU at each boot of the system, so you could easily revert them at any time by simply disabling/uninstalling them and then rebooting the system.

Although I haven't tested this, I'd assume that you could also downgrade to an older microcode version than the one from your BIOS if you manually built an initrd image containing the older microcode version that you want (but I'd of course advise against doing this because it needlessly leaves security vulnerabilities unpatched).

Also, if you are worried against any performance losses incurred by microcode updates, you'd probably still be able to circumvent those by booting with mitigations=off set as kernel parameter in the bootloader (albeit at the expense of security). I'd guess that booting a current kernel with an outdated microcode version would probably cost you more performance because that would cause the kernel to use less efficient mitigations than would be available if you used an up-to-date microcode version.

[ShellCode33]

It seems the fix is now available ! Just upgrade your system and everything should work fine. Thanks a lot @hardfalcon for taking care of it.
I guess this GitHub issue can be closed since it is both fixed and not directly related to linux-hardened

[CodingCellist]

It seems the fix is now available ! Just upgrade your system and everything should work fine. Thanks a lot hardfalcon for taking care of it. I guess this GitHub issue can be closed since it is both fixed and not directly related to linux-hardened

Seems to still repro on my system (kernel 6.5.12-hardened1-1-hardened with lightdm-webkit2-greeter 2.2.5-7). But that will (afaiu) be the case until the relevant WebKit bug (WebKit#262100) is fixed.

In any case, closing this since it's not related to linux-hardened is fine by me : )