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....
Using an int3 has some problems. It can be seen by the code, which may change behavior. For example, a self-checksum would fail. The int3 will affect all threads, while the hardware breakpoint can be made to affect just one thread.
FYI, Joyent SmartOS/illumos is also similarly not vulnerable, at least by default.
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.
 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.
If so: that's a surprising and weird thing to say. Without hardware breakpoints, userspace debuggers work by overwriting the instruction at the target with an interrupting instruction, and then restoring it before resuming.
I'm trying to imagine how gdb breakpoints in OpenBSD would even work if they required single-stepping whole programs.
I don’t think it’s that bad. gdb can (and hopefully does) just replace the target instruction with INT3. IMO the worse implication is that gdb can’t use efficient data breakpoints.
Inefficient data breakpoints still seems like a dealbraker for an OS aiming to be as popular as Windows or Linux, but I can see how OpenBSD can avoid it and still have a good number of users.
I know these aren’t the features in question, but casually dismissing the benefits of CPU improvements doesn’t strike me as productive.
On the other hand, I can’t remember the last time any non-interpreted system I deployed for my own use was too slow, even on low-wattage hardware / smallest available cloud instances.
At some point, “rock solid” is more imporant than “N% faster”.
As hardware gets faster, stability is the dominant consideration for a larger percentage of deployments.
I'd just pick one of many bleeding edge distributions for say a laptop.
Being proud of this is like being proud of not using an MMU.
There is nothing wrong to be proud about esp. given how things have turned out.
> The Meltdown vulnerability primarily affects Intel microprocessors, but some ARM microprocessors are also affected. The vulnerability does not affect AMD microprocessors. Intel has countered that the flaws affect all processors, but AMD has denied this, saying "we believe AMD processors are not susceptible due to our use of privilege level protections within paging architecture".
No matter if you agree or disagree, Theo/OpenBSD made a engineering choice and did what they thought was the right choice for OpenBSD users. As fellow engineers, we should realize how difficult that is, and that the discussion deserves a bit more nuance, depth and respect.
I still don't full understand the trade-offs.