
Meltdown fix committed to OpenBSD - WhyNotHugo
https://undeadly.org/cgi?action=article;sid=20180221201856
======
bcantrill
Great to see this, and congratulations to OpenBSD on landing KPTI! From the
illumos/SmartOS perspective, our collaboration with OpenBSD and DragonFly
engineers has been invaluable[1]; working together, all projects made quicker
progress. Indeed, the cross-project collaboration has been a silver lining to
the very dark cloud of Intel's selective (and irresponsible) disclosure.

[1]
[https://twitter.com/arekinath/status/951321167708606464](https://twitter.com/arekinath/status/951321167708606464)

------
twunde
Congratulations to the OpenBSD team! How crazy is it that the BSDs were not
given notice about the Meltdown/Spectre bugs? Especially considering the
strong security focus of several of these variants

~~~
cthalupa
OpenBSD has a reputation for not respecting embargoes, even as recently as the
KRACK wifi thing last year.

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

~~~
bcantrill
Please stop defending (if implicitly) Intel's irresponsible disclosure. We at
Joyent are (1) a public cloud, (2) have our own operating system (SmartOS),
(3) have always respected embargoes and (4) have a close relationship with
Intel (!!) -- and we weren't notified either. OpenBSD was not excluded --
rather they (and we and every other system that isn't Windows, MacOS and
Linux) were not included. What Intel did here was hugely irresponsible,
leaving many in a vulnerable position for an extended period of time; there is
nothing that OpenBSD (or anyone else) did to deserve such shabby treatment.

~~~
runlevel1
They dropped the ball all around.

Even with 6 months lead time, they were startlingly unprepared in all but
their works-as-designed press release.

~~~
ymse
I think HN user pinewurst nailed it back in 2016: "[Intel] are basically a PR
firm with a good fab in the basement".

[https://news.ycombinator.com/item?id=11820078](https://news.ycombinator.com/item?id=11820078)

Their handling of recent events has really cemented this view in my mind.

~~~
jrockway
I think that was a typo, though, and he meant to refer to IBM.

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.

~~~
ymse
No, it really was in reference to Intel (the thread was about Intel obtaining
and developing a dinosaur-era distributed file system called Lustre).

~~~
bayindirh
Lustre may be old, but it's hardly useless. Some of its capabilities cannot be
replaced by any modern storage systems object and file alike.

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.

------
ams6110
Kernel code is not my area. Is this substantially different from how Linux is
addressing the issue?

~~~
Scaevolus
No, but note that OpenBSD didn't learn about the issue until the public
announcement. Linux developers had months to work on addressing the issue.

~~~
kiallmacinnes
While there are obvious disadvantages to not being told early, could there
have been some advantages? For example, Linux and Windows mitigations already
worked out and ready as a reference?

(I'm not saying those advantages might outweigh the disadvantages, just
speculating on the pros and cons!)

~~~
tedunangst
The basic of concept of separate page tables for user land and kernel is well
known. It's how sparc64 is implemented from the very beginning. But knowing
this is the objective is almost meaningless to actually accomplishing it. The
devil is in the details, of which there are many, and they aren't necessarily
shared.

------
amelius
Is there an automated test for this? Otherwise, I'm worried that at some point
somebody will accidentally break the code and open up the vulnerability again.

~~~
mschuster91
I can't think of a reliable (!) way to do scalable reproducible regression
tests for this sort of hardware bug. Probably you'd need a dog slow version of
qemu with full cpu emulation, no acceleration, and specific hacks to make the
emulated cpu affected by spectre/meltdown.

------
jankotek
Title should be "Meltdown workaround...". It is workaround for buggy CPU, not
problem in BSD itself.

------
yorby
Any chance that Meltdown or Spectre were not backdoors (statistically)?

~~~
PhantomGremlin
How, exactly, does that happen? Do dozens of Intel people all get together in
a conference room?

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?

~~~
speedplane
An intentional backdoor: no. But an intentional ignorance of a major security
vulnerability: extremely likely.

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.

------
davidkuhta
First thought was 'Who is Meltdown Fix, and why are they committed to
OpenBSD?' *smh

Edit: Just meant to comment on the mild linguistic ambiguity in the title.

