10 ms·
Meltdown fix committed to OpenBSD
- ams6110 9y agoKernel code is not my area. Is this substantially different from how Linux is addressing the issue?
- Scaevolus 9y agoNo, but note that OpenBSD didn't learn about the issue until the public announcement. Linux developers had months to work on addressing the issue.
- tclover 9y agoIn Theo we trust
- rurban 9y agoIn this case not really. The OpenBSD impl. looks very costly and is still incomplete. You may wonder why they didn't add a benchmark number to the commit. I suspect there's a lot of pagetable cache trashing going on, with two complete separate pages. See https://news.ycombinator.com/item?id=16441341 https://news.ycombinator.com/item?id=16441341
- kiallmacinnes 9y agoWhile there are obvious disadvantages to not being told early, could there have been some advantages? For example, Linux and Windows mitigations already worked out and ready as a reference? (I'm not saying those advantages might outweigh the disadvantages, just speculating on the pros and cons!)
- kiallmacinnes 9y agoIf you're downvoting, I'd love to know why. I asked an honest question, made no statements to which I can imagine people disagreeing with, and went out of my way to make sure it couldn't be taken in a bad way...
- mfoy_ 9y agoI mean... if you want to be really pedantic, there are technically some silver linings. But the disadvantages outweigh that stretch of a silver lining by so many orders of magnitude that it's almost insulting. It would be like telling a mugging victim: "Hey, at least now you can justify buying a new purse!"
- tedunangst 9y agoThe basic of concept of separate page tables for user land and kernel is well known. It's how sparc64 is implemented from the very beginning. But knowing this is the objective is almost meaningless to actually accomplishing it. The devil is in the details, of which there are many, and they aren't necessarily shared.
- cheeseprocedure 9y agoWas any reasoning made public for this decision? It seems bizarre to have left the *BSD projects in the dark.
- caf 9y agoI have heard it mentioned that the core Linux kernel developers didn't get told months ahead - only some people at Red Hat specifically. Anyone know the truth of that?
- brynet 9y agoThe implementation is of course different, but the workaround is the same, separating the user/kernel pages tables. One key difference is that OpenBSD doesn't have to deal with 32-bit binary compatibility [0] and such, and also has made considerable effort to minimize the amount of kernel pages needed, AFAICT 6+(2*ncpus) [0] https://marc.info/?l=openbsd-misc&m=148926149318522&w=2 https://marc.info/?l=openbsd-misc&m=148926149318522&w=2
- hansendc 9y agoI work on the Linux KPTI/KAISER code (and work at Intel). The high-level description, along with the set of hardware things that get mapped into both kernel/app page tables are basically identical. Creating that list of things was painful, at least for me while I was getting KAISER working. If I were in their position I definitely would have leveraged the list of things that we found in the Linux work. I hope they were able to do that. Some minor differences in the implementations: In Linux, we allocate the two top-level page tables next to each other so we can just flip a bit to switch, and in the OpenBSD commit they seem to be allocating them separately and then storing the two pointers in a per-cpu data structure. Both are fine ways to do it. I don't see anything like the Linux "espfix" mechanism. Guess there isn't one. The BTS/PEBS buffers seem missing. This hardware may just not be supported.
- waynecochran 9y agoHaving separate page tables for user space vs kernel space seems like the right thing to do from the beginning -- I was surprised that they were shared. Could you elaborate on "we allocate the two top-level page tables next to each other so we can just flip a bit to switch"?
- blattimwind 9y agoOther architectures (like SPARC) have had split PTs for like, always. (And they're not optional, either)
- hansendc 9y agoSharing an address space is nice. Programs pass lots of pointers into the kernel (think read()/write()). For the kernel to get at that data, if the kernel and userspace share an address space you can just use the pointer. If userspace has a truly separate set of page tables, you have to do some relatively crazy (and slow) stuff to go and access the data from inside the kernel. It's much harder than just accessing a pointer. We can still do this with KPTI because despite having two page tables, the kernel still continues to map all of userspace. BTW, the bit flipping is pretty much // Allocate 8k which is also 8k aligned: pgd = alloc_pages(PAGE_SIZE*2); That allocates something which might go from (physical address) 0x12340000->12360000. The first top-level pagetable is at 0x12340000 (for the kernel) and the second is at 0x12341000 (for running userspace). So, when you leave the kernel you just set a bit in your CR3 register (well, you do it in assembly, but here it is logically in C): write_cr3(read_cr3() | 0x1000); // 0x12340000 -> 0x12341000 When you come back in to the kernel you clear the bit: write_cr3(read_cr3() & ~0x1000); // 0x12341000 -> 0x12340000
- bcantrill 9y agoGreat to see this, and congratulations to OpenBSD on landing KPTI! From the illumos/SmartOS perspective, our collaboration with OpenBSD and DragonFly engineers has been invaluable[1]; working together, all projects made quicker progress. Indeed, the cross-project collaboration has been a silver lining to the very dark cloud of Intel's selective (and irresponsible) disclosure. [1] https://twitter.com/arekinath/status/951321167708606464 https://twitter.com/arekinath/status/951321167708606464
- twunde 9y agoCongratulations to the OpenBSD team! How crazy is it that the BSDs were not given notice about the Meltdown/Spectre bugs? Especially considering the strong security focus of several of these variants
- cthalupa 9y agoOpenBSD has a reputation for not respecting embargoes, even as recently as the KRACK wifi thing last year. If you have a history of breaking embargoes, you're going to stop getting included in them. Edit: Changed to reflect the explicit nature, as it seems the answer is not all BSDs ;)
- tephra 9y agoNow I don't have all the information at my fingertips but IIRC with KRACK it was OpenBSD (not all the BSDs) that commited the fix early and they _did_ have permission to do this but the security researcher did regret giving this to them. I think (but not really sure someone please correct me) that openbsd has a policy of not signing NDAs but I think freebsd devs are willing. Why they, netbs, or illumos (although I have no information on how they handle these kinds of disclosures) wasn't alerted is beyond me.
- DCKing 9y agoI've heard other variations of this story that stated that OpenBSD simply had the fix ready first, asked permission to commit it (without fanfare), and got it. As far as I remember from the discoverer's CCC talk, OpenBSD got the fix first because he discovered the vulnerability first in OpenBSD's WPA implementation. It's not that OpenBSD did not want to cooperate, it's that there was some miscommunication that ended up not fitting in the coordinated disclosure.
- akerro 9y ago>I've heard other variations of this story that stated that OpenBSD simply had the fix ready first Why dont you reach to the source? >Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. https://www.krackattacks.com/#openbsd https://www.krackattacks.com/#openbsd
- davidkuhta 9y agoFirst thought was 'Who is Meltdown Fix, and why are they committed to OpenBSD?' *smh Edit: Just meant to comment on the mild linguistic ambiguity in the title.
- amelius 9y agoIs there an automated test for this? Otherwise, I'm worried that at some point somebody will accidentally break the code and open up the vulnerability again.
- mschuster91 9y agoI can't think of a reliable (!) way to do scalable reproducible regression tests for this sort of hardware bug. Probably you'd need a dog slow version of qemu with full cpu emulation, no acceleration, and specific hacks to make the emulated cpu affected by spectre/meltdown.
- yorby 9y agoAny chance that Meltdown or Spectre were not backdoors (statistically)?
- PhantomGremlin 9y agoHow, exactly, does that happen? Do dozens of Intel people all get together in a conference room? So an Intel Project Manager comes into the room and says to a bunch of Intel's CPU designers: "the ghost of Andy Grove says we have to put a backdoor in for the NSA. They want it to be obscure. What they want us to do is to speculatively execute instructions across the user/kernel protection boundary. But wait ... don't allow the effects of those instructions to be easily visible. After all, it is nominally a protection boundary. Instead, just make sure to disturb the CPU cache. NSA can then easily observe cache timing changes and use that to read kernel memory. That should be good enough for NSA's needs. But, boy, won't people have a meltdown if this ever becomes widely known?" "Oh, and by the way, top Intel engineers, you must keep this secret 'forever'. You can't tell anyone outside the company. You need to keep this on a 'need to know' with all your fellow design, verification, and test engineers, whom you must swear to secrecy. You can't anonymously leak this, or the NSA will find out and send you off to Gitmo for rendition. Mum's the word." "Also, guys, there's no point in putting in this backdoor for a single chip. We must carry this backdoor forward to every new CPU design team that we bring on for every new CPU chip Intel makes. Sure, some chips are designed in Oregon and some in Israel, and some may even be designed in cyberspace. But we'll be sure to keep this backdoor in all future implementations. We need to let future CPU architects know that they must forever honor this promise we made to the NSA." Yeah, that could have happened. Or, more likely, out of the 1,000,000 design decisions, big and small, that go into creating a modern CPU which has literally billions of transistors, nobody involved thought this was a serious enough concern. If they thought of it at all. Because, ultimately, they get paid for shipping functional silicon rather than for worrying about information leakage in every possible corner case. If this were so simple, why didn't someone figure it out before? Meltdown is mostly Intel, but the similar Spectre exploit affects Intel, ARM, and AMD. And has for many years. Are all the engineers at all of those companies in on this backdoor? Or was the backdoor so diabolically clever that only the "CPU architect cabal" at these companies the only ones who needed to know?
- jankotek 9y agoTitle should be "Meltdown workaround...". It is workaround for buggy CPU, not problem in BSD itself.