“We didn't chase the fad of using every Intel CPU feature”
1–10 of 35 posts
Re: “We didn't chase the fad of using every Intel CPU feature”
#2"We didn't chase the fad of using every tool that was at our disposal". And he's even proud of it, lol
Re: “We didn't chase the fad of using every Intel CPU feature”
#3For context see the CVE[0] and HN discussion[1]
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2018-88...
Re: “We didn't chase the fad of using every Intel CPU feature”
#4This 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....
Re: “We didn't chase the fad of using every Intel CPU feature”
#5"We didn't chase the fad of using every tool that was at our disposal". And he's even proud of it, lol
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?
Re: “We didn't chase the fad of using every Intel CPU feature”
#6"We didn't chase the fad of using every tool that was at our disposal". And he's even proud of it, lol
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
Re: “We didn't chase the fad of using every Intel CPU feature”
#7This 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…
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-deb...
Re: “We didn't chase the fad of using every Intel CPU feature”
#8This 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.
Re: “We didn't chase the fad of using every Intel CPU feature”
#9This 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…
I think the hardware breakpoint support is for breaking on memory accesses to a particular address. Setting a breakpoint on the execution of a particular opcode at a particular address is easier and can be done by just swapping in an "INT 3" instruction at the particular point with no overhead.
Re: “We didn't chase the fad of using every Intel CPU feature”
#10This 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…
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-deb...
That is the kernel debugger that is entered when the system panics. Userland debugger is still gdb.