OpenBSD's De Raadt Pans 'Incredibly Bad' Disclsoure of Intel CPU Bug (itwire.com)

troublemaker_23 quotes ITWire: Disclosure of the Meltdown and Spectre vulnerabilities, which affect mainly Intel CPUs, was handled "in an incredibly bad way" by both Intel and Google, the leader of the OpenBSD project Theo de Raadt claims. "Only Tier-1 companies received advance information, and that is not responsible disclosure -- it is selective disclosure," De Raadt told iTWire in response to queries. "Everyone below Tier-1 has just gotten screwed."
In the interview de Raadt also faults intel for moving too fast in an attempt to beat their competition. "There are papers about the risky side-effects of speculative loads -- people knew... Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies -- so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk."

He points out this will make it more difficult to develop kernel software, since "Suddenly the trickiest parts of a kernel need to do backflips to cope with problems deep in the micro-architecture." And he also complains that Intel "has been exceedingly clever to mix Meltdown (speculative loads) with a separate issue (Spectre). This is pulling the wool over the public's eyes..."

"It is a scandal, and I want repaired processors for free."

Comments

Re:Freedom demands Open Hardware also

[0100010001010011]

Not sure about others but some are available for purchase.

"SiFive has declared that 2018 will be the year of RISC V Linux processors" - Linux Now Has its First Open Source RISC-V Processor, Slashdot.

To answer AC's question a few moths later: "What's the big advantage with RISC over ARM or x86?"

Meltdown, Spetre.

Correction needed

[fubarrr]

>is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk

The specific issue that Pentium line CPUs: a) do privilege check asynchronously; b) do it only for the "winning" execution branch was very well known among CPU design community.

Intel architects even bragged about that as their "innovation" in industry journals and filled a number of patents for that (this is the reason amd privilege checker runs on all branches)

Re:Correction needed

[TheRaven64]

System calls where always slow because they used to be called via a software interrupt call.

And software interrupts were slow because they were not considered branches by early branch predictors and so triggered a complete pipeline flush equivalent to a branch mispredict (followed immediately by another branch, which SYSCALL removed). Intel addressed this by treating software interrupts as normal branches for the branch predictor, with an extra hint that they changed privilege level. This gave a small improvement to the Pentium, but was a huge boost on the Pentium 4, where the pipelines were long and deep enough that they had up to 140 instructions in flight at a time and having to flush all of those for a system call was painful.

Speculative execution does n't mean we have have this problem, AMD managed to do it fine. No one can say this is by design, if it is by design then it should be documented since 1995 that the MMU protection can be bypassed.

Speculative execution across ring changes is the root cause of this. AMD doesn't do this because Intel patented it, told AMD, and didn't include it in their cross-licensing agreement. You can bet that AMD was just waiting for the patent to expire before doing it, because without it you have to wait until all branches up to the system call have been retired before you can perform the transition. The MMU protection isn't bypassed, because the instructions that would be bypassing the MMU protection are cancelled. There is a side channel that allows you use the changes in cache behaviour to determine what the values in memory would have been.

Re:Freedom demands Open Hardware also

[Entrope]

ARM is a RISC architecture, and plenty of RISC architectures suffer from Spectre. Meltdown is an Intel-only bug -- AMD doesn't have it because they implemented an obvious security rule, and presumably Cyrix and other x86 implementations didn't either.

Re:Disagree

[complete loony]

He's just bitter because he got slapped on the wrist last time.

Why did OpenBSD silently release a patch before the embargo?

OpenBSD announced an errata on 30 August 2017 that silently prevented our key reinstallation attacks. More specifically, patches were released for both OpenBSD 6.0 and OpenBSD 6.1.

We notified OpenBSD of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.

Re:Disagree

[TheRaven64]

Sure it does. If you want to keep something quiet until you are ready to announce it, then you DO NOT tell any of the people who have a track record of spilling the beans.

When has FreeBSD ever disclosed a security vulnerability under embargo? FreeBSD has a security officer and a secteam group that are the only ones that have access to any embargoed security information and have separate infrastructure from the rest of the project for preparing fixes. Only people who have signed the relevant NDAs are allowed access to anything shared with this group and they are normally given information about embargoed security issues as a result.

Regardless of where you personally stand on the idea of embargos and standing up for principles, Theo refused to go along with an embargo previously and it was quite likely that he wouldn't do so this time either

You do realise that FreeBSD and OpenBSD are entirely different projects, run by different people, with different infrastructure and different codebases and that Theo De Raadt has no connection to the FreeBSD project?

Re:Core issue is trust

[Christian Smith]

It was also a short and long term benefit of their customers. Are you willing to pay Intel back for the extra performance they provided by their same decision that you are deriding today?

Eh? We've already paid the Intel for the performance. Intel CPUs are that bit more expensive than equivalent AMD CPUs, performance is why they commanded the price premium.

Customers trusted Intel that the performance was gained with no cost to security, a reasonable assumption. I'm computer literate, and I'm shocked that this can even be an issue. How the hell do speculative memory accesses leak through kernel memory protection?

So I'm not sure what you think is to be paid back.

Patent infringement

[sjbe]

No, it's not tricky to pull off.

If it wasn't tricky to pull off then it would have already been done on a wide scale. I'm not saying it's impossible but it is going to be a much tougher nut to crack than open software. Mostly for economic reasons rather than technical ones.

- Research and make use of expired patents extensively, file new ones defensively.

Who is going to do this? Who has the funding and more importantly the incentive to do this? IBM received 8000 patents in 2016 and numerous other tech companies received thousands more each. Exactly how do you plan to match that sort of pace? How do you plan to produce anything really useful without infringing on a pile of those patents? Not to mention fending off the flesh eating lawyers that give those patents teeth...

It's more capital intensive than software, but it's also not that expensive either.

I'm a certified accountant and an industrial engineer. I do cost accounting for a living. It is a LOT more expensive than software no matter how clever you are. There is a reason gross margins in manufacturing hardware are far thinner than in software. You don't escape these costs by just doing design either. Someone eventually has to make the product and that will require substantial capital. Then you have the cost of distributing the product. Unlike software which can be sent across the net for nearly free, hardware has to be shipped, stored and turned into products, all of which cost non trivial amounts of cash. If you think it isn't substantially more expensive than making and distributing software you haven't done the math.

Obligatory:Intel CPU Backdoor Report (Jan 1 2018)

[Anonymous Coward]

Change log:
2018/01/01 - Added 14 Useful Links. Disable Intel ME 11 via undocumented NSA "High Assurance Platform" mode, Blackhat Dec 2017 presentation, Intel ME CVEs (CVSS Scored 9.0-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."

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.

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).

Useful links (Added 2018 Jan 1):
Disabling Intel ME 11 via undocumented mode (NSA High Assurance Platform mode)
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 system privileges to provisioned Intel manageability SKUs
CVE-2017-5705: Multiple buffer overflows in kernel in Intel Manageability Engine Firmware
CVE-2017-5706: Multiple buffer overflows in kernel in Intel Server Platform Services Firmware

Re:Freedom demands Open Hardware also

[AHuxley]

Re "Open hardware is always free of faults."
We have seen what the best names in some sectors of the computing community did for security for years.
PRISM (surveillance program) https://en.wikipedia.org/wiki/...
Open software and open hardware is a good start at having a few people have a look at computer security.
The big brands keep failing.
Generations of failed hardware, junk encryption, CPU's, OS and networking. Backdoors, trapdoors.

Re:He and Linus are Spot On

[OneAhead]

He's also dead right in that Intel has been mixing up the two issues, Meltdown and Spectre, deliberately, so they could tell everyone that it wasn't just Intel that was affected, and they also gave the impression that Spectre had been fixed when it was Meltdown that had been mitigated - with a patch that creates unacceptable performance problems, to a lesser or a greater extent.

This, in spades. While Theo De Raadt is not my favorite IT personality, the mixing together of the issues (actually 3 of them!) has made it exceedingly hard for someone who isn't familiar with the inner working of modern CPU architectures to get the story straight, and Mr. De Raadt gets kudos for calling them out on it.

The following is what I could infer from what I found online. I'm almost certain a good portion of it is WRONG, and I hope the more knowledgeable part of the /. crowd will help me out by correcting it. (No, I'm not being lazy - just stretched to the limit of my understanding of the primary sources, yet desperate to gain some working understanding beyond the "it's hard to explain but you should apply patches" advice found everywhere on the internet.)

• There are three separate but somewhat related issues:
  • Variant 1: bounds check bypass (CVE-2017-5753)
  • Variant 2: branch target injection (CVE-2017-5715)
  • Variant 3: rogue data cache load (CVE-2017-5754)
• Variant 3 is a true bug by any definition. It was named "meltdown" and is an Intel exclusive - AMD and ARM are not affected. If an attacker succeeds to run a malicious binary on an affected system, they can read kernel memory, including juicy secrets like passwords and decription keys. To put this into perspective, this is very nearly as bad as a local privilege escalation. And to put that into perspective, local privilege escalations are so common that there's a mantra in security: if a sufficiently skilled adversary gains "arbitrary code execution", it's virtually "game over" and you can go scrub your HDD. Nevertheless, the aforementioned "sufficiently skilled" bar lies quite high and may not be met by a lot of common threats (especially the automated ones). So, from a defense-in-depth perspective, the only sane advise is "patch your system now". The big news is that patching will come with a performance impact that is proportional with how frequently a process calls the kernel. A process that simply allocates a big chunk of memory, loads data into it, and starts chewing on that (think stuff like compression, crypto mining, scientific computation,...) will not feel much impact, while databases generally will.
• Variant 1, IF I understand correctly, allows an attacker to feed a non-buggy process carefully crafted input that tricks it into leaking data into memory space that is owned by the process in question, but not in use by it. The bad news here is that all CPUs (including AMD and ARM) are vulnerable and there's no way to patch it system-wide. One could argue that this is not a huge deal in and by itself because if the process and the system have no other bugs, the data could never be retrieved. However, it is apparently possible on certain browsers to make JavaScript read data from the "not-in-use" memory locations (which would be a feature for a "system" language like C, but I would classify it as a bug for a high-level interpreted language such as JavaScript). Given that a browser handles sensitive data (passwords), this is potentially devastating. Fortunately, it is easily mitigated by the fact that the leaked data doesn't live long by virtue of it physically only residing in the CPU cache and not the actual memory. The attack therefore relies on precise timing, and by decreasing the precision of the timing mechanisms that are available in JavaScript, browser manufacturers can put a stopgap into th

Re:He and Linus are Spot On

[Lothsahn]

Thank you for noting that you're not 100% sure it's right, and for the excellent summary. There's a ton of misinformation going around, especially with 0100010001010011 dude on Slashdot repeatedly posting that Meltdown is INTEL ONLY, which is false, as some ARM products are affected. What is true is that Meltdown does not affect AMD and affects only a few of ARM's processors.

As you state, it's important to rely on the original sources. Here is each CPU vendor's response to the security issues:
https://www.amd.com/en/corpora...
https://www.intel.com/content/...
https://developer.arm.com/supp...

Here are two corrections to make:
1) Meltdown:
One of your bold statements "AMD and ARM are not affected" is untrue. See here, from ARM directly:
https://developer.arm.com/supp...

ARM has confirmed that A75 is vulnerable to Meltdown. In addition, A15, A57, and A72 are vulnerable to a variant of Meltdown (Variant 3a) which ARM has added. ARM has stated that they believe this variant is NOT exploitable, however, there is already userspace code out there that can do some limited exploits:
https://github.com/lgeek/spec_...

AMD is not affected by Meltdown, in any form. From AMD's press release:
https://www.amd.com/en/corpora...

2) Variant 1: While other vendors may require application changes to address this issue, AMD appears to be able to address this with an OS update, based on their post:
https://www.amd.com/en/corpora...


Summary:
Variant 1: Some manufacturers (ARM) appear to not be able to fix it and are recommending compiler changes, but AMD will fix this in OS updates. Unclear how Intel is addressing this vulnerability.
Variant 2: Correct, from what I can tell.
Variant 3 (Meltdown): Affects nearly all Intel (within the last 10 years) and ARM A75 chips. AMD not affected.
Variant 3a (Modified Meltdown): Affects a larger set of high performance ARM chips

Finally, Intel has done a terrible job (intentionally?) at conflating the two issues, which is unfair. These are 3 separate security issues, with their own priorities and impacts. If you read Intel's official press release for this issue, there's no differentiation between variants 1-3, like there is for AMD and ARM:
https://www.intel.com/content/...

Re:"I want repaired processors for free"

[networkBoy]

Bwahahahahaaaa
it doesn't work that way at all.

Old designs would be for different process technologies. As the tech changes the DRCs (Design rule checks) change as well.

You can't run a design on a process it wasn't made for, the resulting product simply won't work correctly (if at all).

If the CPU was designed for a gate width of 35nM then it was designed with biasing around that gate width's leakage. If you then try to spin that part on a 14nM fab the biasing of the gates is all wrong and it will (likely catch fire) not work at all because of such high leakage.

Additionally, price doesn't scale the way you imply. A wafer start costs about $1K. Doesn't matter what process you run on it (it does, but not really all that much). The cost per part is based on the number of functional parts per wafer at the end. Thus going from an 8 to a 12 inch wafer lowers cost even though the process change requires a $2.2bn fab to be built, you have gone from 201 sq inches to 452 square inches, over *double* the yield.
Same thing from process shrinks, you cut the area used by your transistor gates and you make the die smaller, then you can fit more on a wafer.

Thing is, Intel may not even have fabs capable of making the older parts any more, even if they wanted to. Process tech has evolved, IDK if they even have an 8" fabs left...

To just "redesign" the part for the new process is not realistic either.

TLDR: To make an old part will cost the same or more than it did when it was the latest and greatest.

Re:"I bet they were instructed to ignore the risk"

[TheRaven64]

Bullshit you say, and yet it's only Intel and a few, comparatively insignificant ARM chips which are affected by meltdown, which btw, was what Linus was referring to.

Ye, because Intel patented the technique and didn't license it to anyone else.

I can only presume AMD is an imaginary entity in your little world, because they apparently managed to solve all these impossible problems without handing out the keys to the kingdom to everyone who asked for them.

Nope, AMD pays a higher penalty on system calls, though they mitigate this to some extent by having shorter and narrower pipelines.