Kernel Security Update - RETBLEED - Can we turn mitigation On/Off?
All, The kernel security update described on the announce-list listed the following, among other, problems addressed: The RETBLEED potential leak of info had been in the news the past week or so and a patch was anticipated. However, in discussing the fix, it can affect performance from 9 - 30%. Also discussed was it's "theoretical" use as an exploit to manipulate CPU branch prediction to glean information about kernel security details. - CVE-2022-29900, CVE-2022-29901: Fixed the RETBLEED attack, a new Spectre like Branch Target Buffer attack, that can leak arbitrary kernel information (bsc#1199657). My question here is depending on the impact to performance on any given setup, is there a kernel parameter we can pass at boot to turn it On/Off if the performance impact is severe? The second one is more of a chuckle and a wonder of just how long this bug may have existed - CVE-2022-33981: Fixed use-after-free in floppy driver (bsc#1200692) :) -- David C. Rankin, J.D.,P.E.
On 7/16/22 00:14, Andrei Borzenkov wrote:
On 16.07.2022 01:54, David C. Rankin wrote:
My question here is depending on the impact to performance on any given setup, is there a kernel parameter we can pass at boot to turn it On/Off
retbleed=off
Smacks self for not recognizing the obvious -- but better to ask someone that knows... Thanks Andrei! -- David C. Rankin, J.D.,P.E.
On Sat, Jul 16, 2022 at 01:46:55AM -0500, David C. Rankin wrote:
On 7/16/22 00:14, Andrei Borzenkov wrote:
On 16.07.2022 01:54, David C. Rankin wrote:
My question here is depending on the impact to performance on any given setup, is there a kernel parameter we can pass at boot to turn it On/Off
retbleed=off
Smacks self for not recognizing the obvious -- but better to ask someone that knows...
... also mitigations=off should also work, will disable all of the CPU mitigations. Also see our TID for all the options: https://www.suse.com/support/kb/doc/?id=000020693 Ciao, Marcus
On 16/07/2022 09.40, Marcus Meissner wrote:
On Sat, Jul 16, 2022 at 01:46:55AM -0500, David C. Rankin wrote:
On 7/16/22 00:14, Andrei Borzenkov wrote:
On 16.07.2022 01:54, David C. Rankin wrote:
My question here is depending on the impact to performance on any given setup, is there a kernel parameter we can pass at boot to turn it On/Off
retbleed=off
Smacks self for not recognizing the obvious -- but better to ask someone that knows...
... also mitigations=off should also work, will disable all of the CPU mitigations.
Also see our TID for all the options: https://www.suse.com/support/kb/doc/?id=000020693
How safe is a home machine behind a home router, with trusty local users, with "mitigations=off"? A doc for dummies on that, perhaps? :-) -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
On 7/16/22 03:01, Carlos E. R. wrote:
... also mitigations=off should also work, will disable all of the CPU mitigations.
Also see our TID for all the options: https://www.suse.com/support/kb/doc/?id=000020693
How safe is a home machine behind a home router, with trusty local users, with "mitigations=off"?
A doc for dummies on that, perhaps? :-)
Unless your box is compromised by malware that can either abuse or analyze your CPU branch prediction, then you are fine. Much of the risk behind all of the CPU indirect branch prediction credential leak has been proof of concept proved, but not seen in large scale in the wild. The concern for cloud VMs is more direct that a home machine behind a firewall. El Reg did a good write-up with links on RETBLEED (referencing all of the SPECTRE flaws): Older AMD, Intel chips vulnerable to data-leaking 'Retbleed' Spectre variant Speculative execution side-channels continue to haunt silicon world https://go.reg.cx/tdml/dfd67/62f6e97f/9298d624/44MH?utm_source=daily&utm_medium=newsletter&utm_content=article The Linux Kernel (exhaustive) - Spectre Side Channels Write-up https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/spectre.html You can check which mitigations are active with: # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 and # cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 My take away comes from the: <quote> As with all the Spectre flaws, and offshoots like Hertzbleed, if malware really wants to steal data, there are usually plenty of vulnerabilities in OSes and applications to do just that, or ways of socially engineering the user, without having to manipulate the host processor. That said, if nothing's done about Spectre et al, maybe one day someone will exploit it in the wild in a meaningful way. Also, if you're running virtual machines in a public cloud, you may want to be aware of this security weakness as information about or in your VM could leak to another customer via Retbleed. </quote> So from an "Am I worried about it on my home machines or individual servers behind my firewalls with most of APNIC, AFRINIC, and LATNIC blocked?" standpoint -- No, I'd rather have the 9 - 30% performance hit back than mitigate against mostly theoretical CPU branch prediction exploits. Your risk tolerance may be different. -- David C. Rankin, J.D.,P.E.
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
David C. Rankin -
Marcus Meissner