
“We didn't chase the fad of using every Intel CPU feature” - cnst
https://marc.info/?l=openbsd-misc&m=152600018515730&w=2
======
geofft
This seems a bit too self-congratulatory to be technically meaningful. What
feature did they not use?

From the thread history, it sounds like they provided no way for a userspace
debugger to (ask the kernel to) set a hardware breakpoint on a section of
memory. That means that when you use gdb and set a single breakpoint on some
instruction, gdb must instead fall back on single-stepping the _entire
program_ until it gets there, incurring at least four context switches per
instruction (program being debugged -> exception to kernel -> switch to gdb ->
"nope, not there yet" -> kernel resumes the program for one more instruction).
It does avoid the bug by not letting the CPU defer a debug exception until
after a syscall (because the only mode you get for debug exceptions is the one
that unconditionally delivers it after every instruction), but it also makes
breakpoints basically unusable for large software.

First, this isn't an obscure, recent, or Intel-only feature. It's not like
avoiding RDRAND or anything. Hardware breakpoints are common on basically all
CPUs for exactly this reason.

Second, does anyone actually debug large programs using gdb on OpenBSD? It is
hard for me to read this as saying "We're not vulnerable because we have so
few production users that we can just not have standard development tools that
work reasonably." I know OpenBSD is not the most popular OS, but I didn't
think it was _that_ unpopular....

~~~
notaplumber
OpenBSD just chose not to implement x86 debug register access from userspace.

FYI, Joyent SmartOS/illumos is also similarly not vulnerable, at least by
default.

[https://kb.cert.org/vuls/id/631579](https://kb.cert.org/vuls/id/631579)

~~~
ajross
Which is to say, no hardware support for watchpoints in gdb[1]? That seems
like not such a great "feature"...

This is Theo being Theo. No one sane believes that if someone had come to
OpenBSD with an implementation of this (very useful!) feature that they
wouldn't have committed it. They just didn't get around to it.

[1] In which the fallback is, IIRC, to turn off access to the location at the
mapping level and take a SIGSEGV on every access to the 4k region containing
the address.

------
stochastic_monk
Personally, I think it’s valuable to take advantage of new features. AVX512
can be dozens of times faster than scalar operations, and clhash is the
fastest strongly universal string hash library. There’s no good reason to pass
on these kinds of performance improvements.

I know these aren’t the features in question, but casually dismissing the
benefits of CPU improvements doesn’t strike me as productive.

~~~
yjftsjthsd-h
I like performance. But. OpenBSD supports hardware versions a long way back.
So you either break compatibility, ship more versions, or have to detect
features on the fly, which works but has costs. On the other hand, if _all_
x86_64 (amd64) supports a feature then it seems like a better bet.

------
ChrisSD
For context see the CVE[0] and HN discussion[1]

[0] [https://cve.mitre.org/cgi-
bin/cvename.cgi?name=3DCVE-2018-88...](https://cve.mitre.org/cgi-
bin/cvename.cgi?name=3DCVE-2018-8897)

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

------
DannyBee
Right, that most faddiest of fads, "hardware memory breakpoints".

Being proud of this is like being proud of not using an MMU.

------
ahbs66
"We didn't chase the fad of using every tool that was at our disposal". And
he's even proud of it, lol

~~~
GalacticDomin8r
Since he was right to do so and also right about the underlying meltdown
issue, perhaps deserves more than ridicule?

~~~
rhaps0dy
Huh, in what way was Theo right about Meltdown? Did he predict it? (just
curious)

~~~
yawaramin
He predicted similar in 2007: [https://marc.info/?l=openbsd-
misc&m=118296441702631&w=2](https://marc.info/?l=openbsd-
misc&m=118296441702631&w=2)

~~~
jcranmer
That's not anywhere close to a prediction of Meltdown. Meltdown is a side-
channel attack that can cross the user/kernel boundary. What Theo was
predicting is that all chips are getting complex MMUs to the point that there
are bugs in corner cases that could be exploited to create infiltration leaks.
Side channel attacks aren't bugs, insofar as no one is really promising that
you can't observe side channels.

~~~
yawaramin
But the observable out-of-order execution used by these chips that led to
Meltdown is a bug. Proof: AMD chips aren't affected by it:

> The Meltdown vulnerability primarily affects Intel microprocessors,[52] but
> some ARM microprocessors are also affected.[53] The vulnerability does not
> affect AMD microprocessors.[19][54][55][56] Intel has countered that the
> flaws affect all processors,[57] but AMD has denied this, saying "we believe
> AMD processors are not susceptible due to our use of privilege level
> protections within paging architecture".[58]

[https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili...](https://en.wikipedia.org/wiki/Meltdown_\(security_vulnerability\))

