6 ms·

“We didn't chase the fad of using every Intel CPU feature”

141 points by cnst 8y ago

ahbs66 8y ago
"We didn't chase the fad of using every tool that was at our disposal". And he's even proud of it, lol
- nottorp 8y ago
  Question: say you know 5 programming languages and 20 UI libraries. If tasked to write an application, you will attempt to use them all in the project?
  - ahbs66 8y ago
    That's a strawman. Your question is ridiculous. Features of a certain language/framework/etc != languages/frameworks/etc
    - benchaney 8y ago
      That doesn’t make it a straw man, because the argument you made applies equally well to languages/frameworks and to their features.
    - nottorp 8y ago
      Let's try again: would you work on your car using a chainsaw because it happens to be in your tool box?
      - ahbs66 8y ago
        No. I would use a more appropriate tool, because I will never refuse to use anything that's in my toolbox, like Theo did. :)
        guitarbill 8y ago
        That's fine, but not a great analogy. Because once you ship software, everybody has access to that tool. 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.
- GalacticDomin8r 8y ago
  Since he was right to do so and also right about the underlying meltdown issue, perhaps deserves more than ridicule?
  - rhaps0dy 8y ago
    Huh, in what way was Theo right about Meltdown? Did he predict it? (just curious)
    - yawaramin 8y ago
      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 8y ago
        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 8y ago
        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_vulnerability) https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili...
  - sverige 8y ago
- sremani 8y ago
  May be they have lucked out or may that is their ethos, that lets not use some of these optimizations until they have survived test of time. There is nothing wrong to be proud about esp. given how things have turned out.
ChrisSD 8y ago
For context see the CVE[0] and HN discussion[1] [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2018-8897 https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2018-88... [1] https://news.ycombinator.com/item?id=17037862 https://news.ycombinator.com/item?id=17037862
geofft 8y ago
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....
- ianai 8y ago
  Quicker google leads me to believe they suggest using ddb instead of gdb. I’ve seen variations on the following thread a few times. I,don’t,know,whether this answers your question or not. http://openbsd-archive.7691.n7.nabble.com/on-line-kernel-debugging-td335833.html http://openbsd-archive.7691.n7.nabble.com/on-line-kernel-deb...
  - notaplumber 8y ago
    That is the kernel debugger that is entered when the system panics. Userland debugger is still gdb.
- amluto 8y ago
  > gdb must instead fall back on single-stepping the entire program until it gets there 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.
DannyBee 8y ago
Right, that most faddiest of fads, "hardware memory breakpoints". Being proud of this is like being proud of not using an MMU.
stochastic_monk 8y ago
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.
- reacharavindh 8y ago
  True. But, not implementing all intel CPU features "right away" would not be such a bad idea. As a security conscious OS environment, they're wise to not implement certain features until there is a proven need for them/or until there is mature understanding of the features. I for one choose Debian or OpenBSD for such needs. I don't need my firewall appliance(pf + OpenBSD) to be in a hurry to implement AVX512 for example. I'd just pick one of many bleeding edge distributions for say a laptop.
- yjftsjthsd-h 8y ago
  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.
  - deleted 8y ago
    [deleted]
- hedora 8y ago
  For performance sensitive deployments, I agree. 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.

141 points by cnst 8y ago

ahbs66 8y ago

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

nottorp 8y ago
Question: say you know 5 programming languages and 20 UI libraries. If tasked to write an application, you will attempt to use them all in the project?
- ahbs66 8y ago
  That's a strawman. Your question is ridiculous. Features of a certain language/framework/etc != languages/frameworks/etc
  - benchaney 8y ago
    That doesn’t make it a straw man, because the argument you made applies equally well to languages/frameworks and to their features.
  - nottorp 8y ago
    Let's try again: would you work on your car using a chainsaw because it happens to be in your tool box?
    - ahbs66 8y ago
      No. I would use a more appropriate tool, because I will never refuse to use anything that's in my toolbox, like Theo did. :)
      - guitarbill 8y ago
        That's fine, but not a great analogy. Because once you ship software, everybody has access to that tool. 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.
GalacticDomin8r 8y ago
Since he was right to do so and also right about the underlying meltdown issue, perhaps deserves more than ridicule?
- rhaps0dy 8y ago
  Huh, in what way was Theo right about Meltdown? Did he predict it? (just curious)
  - yawaramin 8y ago
    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 8y ago
      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 8y ago
        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_vulnerability) https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili...
- sverige 8y ago
sremani 8y ago
May be they have lucked out or may that is their ethos, that lets not use some of these optimizations until they have survived test of time. There is nothing wrong to be proud about esp. given how things have turned out.

ChrisSD 8y ago

For context see the CVE[0] and HN discussion[1] [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2018-8897 https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2018-88... [1] https://news.ycombinator.com/item?id=17037862 https://news.ycombinator.com/item?id=17037862

geofft 8y ago

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

ianai 8y ago
Quicker google leads me to believe they suggest using ddb instead of gdb. I’ve seen variations on the following thread a few times. I,don’t,know,whether this answers your question or not. http://openbsd-archive.7691.n7.nabble.com/on-line-kernel-debugging-td335833.html http://openbsd-archive.7691.n7.nabble.com/on-line-kernel-deb...
- notaplumber 8y ago
  That is the kernel debugger that is entered when the system panics. Userland debugger is still gdb.
amluto 8y ago
> gdb must instead fall back on single-stepping the entire program until it gets there 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.

DannyBee 8y ago

Right, that most faddiest of fads, "hardware memory breakpoints". Being proud of this is like being proud of not using an MMU.

stochastic_monk 8y ago

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.

reacharavindh 8y ago
True. But, not implementing all intel CPU features "right away" would not be such a bad idea. As a security conscious OS environment, they're wise to not implement certain features until there is a proven need for them/or until there is mature understanding of the features. I for one choose Debian or OpenBSD for such needs. I don't need my firewall appliance(pf + OpenBSD) to be in a hurry to implement AVX512 for example. I'd just pick one of many bleeding edge distributions for say a laptop.
yjftsjthsd-h 8y ago
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.
- deleted 8y ago
  [deleted]
hedora 8y ago
For performance sensitive deployments, I agree. 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.