Meltdown fix committed to OpenBSD
undeadly.org
undeadly.org
If you have a history of breaking embargoes, you're going to stop getting included in them.
Edit: Changed to reflect the explicit nature, as it seems the answer is not all BSDs ;)
I think (but not really sure someone please correct me) that openbsd has a policy of not signing NDAs but I think freebsd devs are willing. Why they, netbs, or illumos (although I have no information on how they handle these kinds of disclosures) wasn't alerted is beyond me.
It's not that OpenBSD did not want to cooperate, it's that there was some miscommunication that ended up not fitting in the coordinated disclosure.
Why dont you reach to the source?
>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.
I can't speak for other BSDs, but I'm not aware of any time in the past 15 years when FreeBSD has failed to respect an embargo.
Even with 6 months lead time, they were startlingly unprepared in all but their works-as-designed press release.
https://news.ycombinator.com/item?id=11820078
Their handling of recent events has really cemented this view in my mind.
You have to remember that IBM's PR is stuff like "Watson is sitting here curing cancer right now while his best friend Deep Blue beats people at chess!!11!" Intel doesn't do any of that.
CEPH comes close, but cannot completely replace it.
When you connect a thousand nodes to a single storage pool with high throughput and low latency requirements, not everything can cut it.
While it's fair to criticize them, sometimes it comes across as "those hardware bozos don't know what they're doing" and hardware design, at the speeds and features Intel does is hard (just look at the number of competitors)
Then there are other segments including Gamers and Casual users, who really believe in Intel's brand and could careless about what Intel did.
Basically we dont see any damages being done to Intel. And when their PR spin how good their 10nm is and Intel being the underdog with Qualcomm in Modem race, everyone would have forgotten about Meltdown and Spectre.
OpenBSD followed [0] the original embargo from the KRACK researcher, he gave OpenBSD the go-ahead to commit it.. only later we he got CERT involved did they want to delay it for more months. He changed his mind retroactively. It's even stated in the original FAQ for that particular security issue.
Enough already? This has nothing to do with Intel's very selective disclosure of Meltdown.
[0] https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbh...
It's also not limited to just KRACK. With the OpenSSL/LibreSSL stuff back in 2015, OpenBSD wasn't part of the disclosure because Theo said he wasn't going to deal with an email-list or embargoes prior to that. Marc Espie has said he thinks it's a good thing that the KRACK embargo was broken early.
In fact, your original link is quite explicit.
>Then he got CERT (and, thus, US gov agencies) involved and had to extend the embargo even further until today. At that point we already had the ball rolling and decided to stick to the original agreement with him, and he gave us an agreeing nod towards that as well.
So, stsp pretty specifically says "It got extended, we decided not to follow the new date, and he went 'well, okay'"
https://www.krackattacks.com/#openbsd
>To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
If OpenBSD did nothing wrong, it seems quite odd that the same person who you are saying was fully on board with it is now explicitly saying he is going to provide late notifications.
You should read the rest of what you linked, and check the dates carefully.
> As a compromise, I allowed them to silently patch the vulnerability.
It's pretty easy to argue that OpenBSD doesn't like embargoes, but it's pretty hard to argue that they ignore embargoes and patch whenever they want to. In this specific case, the project asked and received permission to patch early. The fact that the researcher regrets this in hindsight is beside the point.
He regrets coming to that compromise when they pushed back. They still pushed back and did not want to follow the extension.
Stop spreading this FUD. OpenBSD developers were allowed to make the patch silently, they contacted the KRACK researcher and he agreed to this. HE CHANGED HIS MIND LATER, after the patch went it and he started blaming OBSD and spreading bullshit.
>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.
He asked them to respect the extension. They pushed back against it. Rather than making a big fight about it, he shrugged and went "Well, fine, whatever"
It was obviously not an amenable thing to him, because he's specifically not even going to give them the same level of warning with the understanding they must respect the full embargo period, because right after the bit you quoted, he says:
>To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
If it was just him going "Yeah dudes go for it it's cool everyone else will have to wait out the extended embargo but you can just release the patch immediately!" he wouldn't be punishing OpenBSD for it.
(I'm not saying those advantages might outweigh the disadvantages, just speculating on the pros and cons!)
I asked an honest question, made no statements to which I can imagine people disagreeing with, and went out of my way to make sure it couldn't be taken in a bad way...
It would be like telling a mugging victim: "Hey, at least now you can justify buying a new purse!"
The high-level description, along with the set of hardware things that get mapped into both kernel/app page tables are basically identical. Creating that list of things was painful, at least for me while I was getting KAISER working. If I were in their position I definitely would have leveraged the list of things that we found in the Linux work. I hope they were able to do that.
Some minor differences in the implementations: In Linux, we allocate the two top-level page tables next to each other so we can just flip a bit to switch, and in the OpenBSD commit they seem to be allocating them separately and then storing the two pointers in a per-cpu data structure. Both are fine ways to do it.
I don't see anything like the Linux "espfix" mechanism. Guess there isn't one.
The BTS/PEBS buffers seem missing. This hardware may just not be supported.
Could you elaborate on "we allocate the two top-level page tables next to each other so we can just flip a bit to switch"?
We can still do this with KPTI because despite having two page tables, the kernel still continues to map all of userspace.
BTW, the bit flipping is pretty much
// Allocate 8k which is also 8k aligned: pgd = alloc_pages(PAGE_SIZE*2);
That allocates something which might go from (physical address) 0x12340000->12360000. The first top-level pagetable is at 0x12340000 (for the kernel) and the second is at 0x12341000 (for running userspace).
So, when you leave the kernel you just set a bit in your CR3 register (well, you do it in assembly, but here it is logically in C):
write_cr3(read_cr3() | 0x1000); // 0x12340000 -> 0x12341000
When you come back in to the kernel you clear the bit:
write_cr3(read_cr3() & ~0x1000); // 0x12341000 -> 0x12340000
So an Intel Project Manager comes into the room and says to a bunch of Intel's CPU designers: "the ghost of Andy Grove says we have to put a backdoor in for the NSA. They want it to be obscure. What they want us to do is to speculatively execute instructions across the user/kernel protection boundary. But wait ... don't allow the effects of those instructions to be easily visible. After all, it is nominally a protection boundary. Instead, just make sure to disturb the CPU cache. NSA can then easily observe cache timing changes and use that to read kernel memory. That should be good enough for NSA's needs. But, boy, won't people have a meltdown if this ever becomes widely known?"
"Oh, and by the way, top Intel engineers, you must keep this secret 'forever'. You can't tell anyone outside the company. You need to keep this on a 'need to know' with all your fellow design, verification, and test engineers, whom you must swear to secrecy. You can't anonymously leak this, or the NSA will find out and send you off to Gitmo for rendition. Mum's the word."
"Also, guys, there's no point in putting in this backdoor for a single chip. We must carry this backdoor forward to every new CPU design team that we bring on for every new CPU chip Intel makes. Sure, some chips are designed in Oregon and some in Israel, and some may even be designed in cyberspace. But we'll be sure to keep this backdoor in all future implementations. We need to let future CPU architects know that they must forever honor this promise we made to the NSA."
Yeah, that could have happened.
Or, more likely, out of the 1,000,000 design decisions, big and small, that go into creating a modern CPU which has literally billions of transistors, nobody involved thought this was a serious enough concern. If they thought of it at all. Because, ultimately, they get paid for shipping functional silicon rather than for worrying about information leakage in every possible corner case.
If this were so simple, why didn't someone figure it out before? Meltdown is mostly Intel, but the similar Spectre exploit affects Intel, ARM, and AMD. And has for many years.
Are all the engineers at all of those companies in on this backdoor? Or was the backdoor so diabolically clever that only the "CPU architect cabal" at these companies the only ones who needed to know?
Computer architects have been aware of covert channels for literally decades, from heat signatures, to CPU usage... heck it's even taught in most CS or ECE Master degrees with respect to caching. I wouldn't go as far as saying these two vulnerabilities were "obvious" to most programmers or computer engineers, but they must have been known to many people at the major chip-makers. Someone must have raised it some meeting, probably multiple meetings, and were probably shot down.
So not a conspiracy theory, just lack of proper incentives to keep products secure.
Though you could make the argument that it's likely some people knew about them and didn't say, but that's a different argument I think.
Edit: Just meant to comment on the mild linguistic ambiguity in the title.