Linux 5.19-rc8 Still Getting Bandaged From Retbleed Mitigation Fallout

[phoronix]

Phoronix: Linux 5.19-rc8 Still Getting Bandaged From Retbleed Mitigation Fallout

While normally big CPU security mitigation work done behind closed-doors is in good shape for the vulnerability embargo date, Retbleed has been an exception. Nearly two weeks since Retbleed was made public, the Linux kernel patches around it continue with more now sent in today ahead of Linux 5.19-rc8 to address fallout from the mitigation handling...

https://www.phoronix.com/news/Linux-5.19-More-Retbleed-Fixes

[MastaG]

That's why I use: mitigations=off on all of my Linux workstations.

[milkylainen]

Actual exploits in the wild & alive using CPU side channels?

[evasb]

mitigations=off is increasingly becoming a compelling option.

[Grinch]

That's why I use: mitigations=off on all of my Linux workstations.

I benchmarked productive stuff I do regularly, like rendering, simulations, encoding, and I didn't see any noticeable difference between mitigations=on/off passed as a kernel boot parameter. That said I expect this to hit things like file IO a lot more, and I haven't benchmarked that.

Retbleed looks really severe though, I have a Zen2 3700x which is impacted, so once the patch hits my distro kernel, I'll be benchmarking to see what the impact is for my daily use.

[NateHubbard]

mitigations=off is increasingly becoming a compelling option.

I'm starting to feel that way too. Is there any actual exploit you'd be opening a workstation up to? It doesn't seem like it.

[Developer12]

I'm sorry, we're only *just now* doing IBPB before firmware (EFI) entry?

We've known since 2018 that firmware runs at a high level of privilege and contains exploitable gadgets. Yet another thing that seems to have slipped through the cracks, along with the need to return-stack-stuff on skylake. From how it *sounded,* that stuffing work was completed in 2018 and merged (after initial headaches), but here we are.

But this? Doing an IBPB before firmware entry is *cheap.* Linux uses EFI services so rarely that you can pretty much do whatever and won't see an impact. Everyone has also had *four years* now to get it done.

What that says to me me is there is strong complacency instead of due diligence for *all mitigations* because *some* happened to be expensive. The only ones anyone is eager to patch are those that have immediate and severe proofs-of-concept (retbleed and meltdown). [1]

Frankly, it's emblematic of where security is at as a whole. We wait until something horrible happens and then roll out reactive patches after the fact to close *that* loophole. Memory issues have been known for decades and it's only very recently someone got around to implementing a language with an ownership model and mandatory compile-time verification.

[1] Could be worse: none of the BSDs have bothered to scan for and mitigate Bounds Check Bypass (variant 1). It was a fucking miracle that NetBSD bothered to turn off branch prediction on K10, along with redhat. The mainline kernel still doesn't and probably never will.

[Vorpal]

Can any of this stuff be exploited from JavaScript or webassembly in a browser? That is the only untrusted code I run on my laptop and desktop.

It would be good if you could turn mitigations on for specific processes. For some vulnerabilities that won't make sense I expect but for others perhaps?

[lectrode]

Actual exploits in the wild & alive using CPU side channels?

According to this article, a company called "Immunity Inc" created the first known "fully weaponized" spectre exploit in March of last year. It dumps sensitive information from /etc/shadow. That exploit is available to anyone willing to pay for the containing suite.

On Retbleed's site, there is a demonstration using the new vulnerability to do the same thing: dump sensitive information from /etc/shadow (specifically, the root password hash).

Coming across malware using these in the wild seems substantially more likely now than a year and a half ago. Hopefully, people still insisting on using "mitigations=off" are restricting usage of those devices to non-critical purposes (i.e. gaming) and refraining from logging into bank accounts.

[archkde]

mitigations=off is increasingly becoming a compelling option.

Don't forget adding nobarrier to all your fstab entries. Switching to Microsoft Windows XP may also be a good option.

In all seriousness, don't do any of the above. Turning mitigations off is basically chmod 644 /dev/kmem. The option you should really consider is mitigations=auto,nosmt.