Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

marc.info

Post reply on HN
Print view View original

11–20 of 35 posts

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

#11

Post by geofft »

amluto wrote: post #8
geofft wrote: post #4

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 get…

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

Oh, right, yes.

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.

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

#12

Post by notaplumber »

geofft wrote: post #4

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 get…

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

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

#13

Post by GalacticDomin8r »

ahbs66 wrote: post #2

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

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

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

#14

Post by benchaney »

ahbs66 wrote: post #6
nottorp wrote: post #5

Earlier quoted context omitted.

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?

That's a strawman. Your question is ridiculous. Features of a certain language/framework/etc != languages/frameworks/etc

That doesn’t make it a straw man, because the argument you made applies equally well to languages/frameworks and to their features.

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

#15

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

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

#16

Post by ajross »

notaplumber wrote: post #12
geofft wrote: post #4

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 get…

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

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.

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

#17

Post by reacharavindh »

stochastic_monk wrote: post #15

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.

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.

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

#18

Post by rhaps0dy »

GalacticDomin8r wrote: post #13
ahbs66 wrote: post #2

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

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

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

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

#19

Post by bionsystem »

notaplumber wrote: post #12
geofft wrote: post #4

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 get…

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

It's crazy that DragonFlyBSD took so little time to fix it. I can understand from Microsoft/Xen/Ubuntu to take only 1 day since they have so much people working/depending on it, but it shows great competence and dedication for such a "small" project as DF to solve it in 1 day. Respect.

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

#20

Post by yawaramin »

rhaps0dy wrote: post #18
GalacticDomin8r wrote: post #13

Earlier quoted context omitted.

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

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

He predicted similar in 2007: https://marc.info/?l=openbsd-misc&m=118296441702631&w=2
Post reply on HN