Slashdot Mirror
Linus Torvalds Calls Intel Patches 'Complete and Utter Garbage' (lkml.org)
An anonymous reader writes:
On the Linux Kernel Mailing List, Linus Torvalds ended up responding to a long-time kernel developer (and former Intel engineer) who'd been describing a new microcode feature addressing Indirect Branch Restricted Speculation "where a future CPU will advertise 'I am able to be not broken' and then you have to set the IBRS bit once at boot time to *ask* it not to be broken."
Linus calls it "very much part of the whole 'this is complete garbage' issue. The whole IBRS_ALL feature to me very clearly says 'Intel is not serious about this, we'll have a ugly hack that will be so expensive that we don't want to enable it by default, because that would look bad in benchmarks'. So instead they try to push the garbage down to us. And they are doing it entirely wrong, even from a technical standpoint. I'm sure there is some lawyer there who says 'we'll have to go through motions to protect against a lawsuit'. But legal reasons do not make for good technology, or good patches that I should apply."
Later Linus says forcefully that these "complete and utter garbage" patches are being pushed by someone "for unclear reasons" -- and adds another criticism. The whole point of having cpuid and flags from the microarchitecture is that we can use those to make decisions. But since we already know that the IBRS overhead is huge on existing hardware, all those hardware capability bits are just complete and utter garbage. Nobody sane will use them, since the cost is too damn high. So you end up having to look at "which CPU stepping is this" anyway. I think we need something better than this garbage.
Linus calls it "very much part of the whole 'this is complete garbage' issue. The whole IBRS_ALL feature to me very clearly says 'Intel is not serious about this, we'll have a ugly hack that will be so expensive that we don't want to enable it by default, because that would look bad in benchmarks'. So instead they try to push the garbage down to us. And they are doing it entirely wrong, even from a technical standpoint. I'm sure there is some lawyer there who says 'we'll have to go through motions to protect against a lawsuit'. But legal reasons do not make for good technology, or good patches that I should apply."
Later Linus says forcefully that these "complete and utter garbage" patches are being pushed by someone "for unclear reasons" -- and adds another criticism. The whole point of having cpuid and flags from the microarchitecture is that we can use those to make decisions. But since we already know that the IBRS overhead is huge on existing hardware, all those hardware capability bits are just complete and utter garbage. Nobody sane will use them, since the cost is too damn high. So you end up having to look at "which CPU stepping is this" anyway. I think we need something better than this garbage.
You are right, Linus, as usual.
But I'd prefer the Linux Kernel Development team to push a complete proposal on the table.
Like totally ditching the support to Intels starting with the releases on next March 1st (or better April?).
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
So Linus what are you proposing as the solution? or this just yet another useless rant. Respect everything you have done but Christ sometimes you go on with utter bullshit. Yes we all know the intel situation is shit, yes we all know the patches are fucking awful with huge performance impacts, but what other option have you come up with to avoid it?
From the email correspondance; Linus says to mr Woodhouse:
"As it is, the patches are COMPLETE AND UTTER GARBAGE.
They do literally insane things. They do things that do not make
sense. That makes all your arguments questionable and suspicious. The
patches do things that are not sane.
WHAT THE F*CK IS GOING ON?"
In the post, Linus is not addressing much technical detail (just mentions "garbage MSR writes" whatever than means), but his bullshit detector goes off big time.
It is clear that he thinks the patches are sub-optimal, but that in itself cannot be the first time in Linux kernel history. There seems to be something else behind, or why would he ask "WHAT THE F*CK IS GOING ON" question? Why does he play the "questionable" and "suspicious" card? Does he think that there is something shady going on from Intel, that goes beyond the technical stuff?
Can anyone shed some light?
So I'm gonna submit his email as evidence in my small claims court action against Intel.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Change log:
2018/01/01 - Added 14 Useful Links. Disable Intel ME via undocumented NSA "High Assurance Platform" mode with me_cleaner, Blackhat Dec 2017 Intel ME presentation, Intel ME CVEs (CVSS Scored 7.2-10.0)
Intel CPU Backdoor Report
The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.
What we know about Intel CPU backdoors so far:
TL;DR version
Your Intel CPU and Chipset is running a backdoor as we speak.
The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.
30C3 Intel ME live hack:
[Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
@21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Quotes] Vortrag:
"the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".
"We can permanently monitor the keyboard buffer on both operating system targets."
Decoding Intel backdoors:
The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.
If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).
Backdoor removal:
The backdoor firmware can be removed by following this guide using the me_cleaner script.
Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.
2017 Dec Update:
Intel ME on recent CPUs may be disabled by enabling the undocumented NSA HAP mode, use me_cleaner with -S option to set the HAP bit, see me_cleaner: HAP AltMeDisable bit.
Useful links (Added 2018 Jan 1):
Disabling Intel ME 11 via undocumented HAP mode (NSA High Assurance Platform mode)
me_cleaner: Set HAP AltMeDisable bit with -S option
Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine
EFF: Intel's Management Engine is a security hazard, and users need a way to disable it
Sakaki's EFI Install Guide/Disabling the Intel Management Engine
Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws.
CVE-2017-5689: An unprivileged network attacker could gain
You make some really interesting points around retpoline, but I wonder if this latest from Intel fails to account for this because they are being disingenuous, or because they continue to be a bunch of idiots?
We're seeing similar problems to this with other very-long-established technologies, such as Windows [with Windows 10]. Things that have worked for decades up until W10 are breaking, or they are breaking in new and frustrating ways.
For example, I have a triple-screen setup and using removable SSDs via a caddy unit, I can boot my computer into 2 different W10 instances, as well as multiple Linux builds. The 2 W10 instances behave in completely different ways, despite being set up, by me, with EXACTLY the same approach [scripted]. On one of them the Task Bar keeps relocating itself around the desktop, on the other it remains static. I've been back-and-forth with Microsoft and they don't know why...
At the root of the problem I suspect they have changed something in W10, written by someone no longer at the company, possibly poorly documented and possibly with unknown consequences.
Maybe Intel are having similar issues... A decision was made a very long time ago to do something insecure and stupid with speculative execution, but the person who made that decision is no longer with the company, so a new Team are trying to fix it and simply don't know what they're doing...
I honestly don't know what the source is, but I do know that I am seeing "existing" functionality break with much greater frequency on core platforms like this. It just smacks of carelessness...