3 ms·

No, 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 ago
In Theo we trust
- rurban 9y ago
  In 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 ago
While 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 ago
  If 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 ago
  I 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 ago
  The 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 ago
Was any reasoning made public for this decision? It seems bizarre to have left the *BSD projects in the dark.
caf 9y ago
I 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?

tclover 9y ago

In Theo we trust

rurban 9y ago
In 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 ago

While 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 ago
If 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 ago
I 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 ago
The 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 ago

Was any reasoning made public for this decision? It seems bizarre to have left the *BSD projects in the dark.

caf 9y ago

I 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?