3 ms·

I like OpenBSD, but I wish all these OpenBSD articles stopped repeating the fake news that it invented W^X. Some of us were alive back then, and know that's not

I like OpenBSD, but I wish all these OpenBSD articles stopped repeating the fake news that it invented W^X. Some of us were alive back then, and know that's not true. It invented the name W^X (a name that's technically incorrect because it's possible to have read-only pages that are not executable). But grsecurity patches had had it on Linux for, I believe, years. I'd been running it for a long time in any case. OpenBSD copied W^X, and copied it poorly. E.g. in the first version they said "this cannot be done on 32bit x86". That's funny, because grsec/pax patches did exactly that. OpenBSD eventually realized this, and copied that too. It was first in a mainstream OS to do it, yes. But that's not "inventing it". That said, OpenBSD is a nice system. It would not allow the wave of extreme instability that Linux has gotten lately in the form of systemd. OpenBSD folks would not accept init and other core services crashing regularly. I just need a bit more hardware support, and I'll switch. I'm fixing some of the blockers preventing me from switching as we speak. Biggest thing I'll miss from Linux is Wayland. I hope that comes to OpenBSD soon.

wahern 5y ago
Publishing kernel patches is one thing; publishing an entire operating system distribution where everything runs properly out-of-the-box with those patches enabled by default is quite another. Yes, PaX kernel patches were published in October 2000, 3 years before OpenBSD made an official release with W^X (OpenBSD 3.3, May 2003). But without extensive changes in user space to ensure that data and code were separated in object files, you ended up with alot of complexity, and that complexity ultimately turned out to make PaX significantly less effective: https://lwn.net/Articles/126986/ https://lwn.net/Articles/126986/ Indeed, that's always been the problem with grsecurity patches in general--poor system integration which they've often tried to overcome with sophisticated (arguably overly sophisticated) methods. Neither grsecurity nor OpenBSD "invented" PaX/W^X. They were using pre-existing hardware features designed precisely for this type of capability, it just was never comprehensively employed by a major operating system because it required extensive changes not only to kernels but also, as it turns out, to userland.
- knorker 5y ago
  > Publishing kernel patches is one thing; publishing an entire operating system distribution where everything runs properly out-of-the-box with those patches enabled by default is quite another. That's exactly my point. That's why I find it so annoying that these articles say the wrong thing. > Neither grsecurity nor OpenBSD "invented" PaX/W^X. They were using pre-existing hardware features designed precisely for this type of capability, The first version of PaX predate the page table no-execute bit in x86 hardware, and I believe (eventually) W^X didn't require it either. So no it was not a matter of merely starting to use existing hardware capability. That's why it even was an invention in the first place. Everything got vastly easier once the page-level execute bit was launched in hardware. At the time, when OpenBSD was asked "why aren't you looking at what PaX did?", and they answered that "we don't care what others in the industry are doing". Which is a strange way to think you can create the best security. So Linux patches: 2000. OpenBSD: 2003. Windows: 2004. (not saying OpenBSD didn't do it better, because they don't care about binary compatability, making it easier) If OpenBSD had "invented" it, then how could microsoft possibly have launched it only one year later? Again, I do credit OpenBSD for being the first OS to do these things by default on an OS. But that is, as you said, is "quite another [thing]" from inventing it.
  - wahern 5y ago
    PaX and W^X use segmentation on x86. x86 code segments were by design and definition non-writable--you couldn't write to any region in a code segment unless a writable data or stack segment overlapped the same region. This was a deliberate feature of the hardware that happened to go unused in favor of flat memory models in the most popular operating systems.
    - knorker 5y ago
      No. PaX has both SEGMEXEC and PAGEEXEC. PAGEEXEC does not use segmentation, and works without page-level HW support by using the split data/code TLB. https://en.wikipedia.org/wiki/Executable_space_protection#PaX https://en.wikipedia.org/wiki/Executable_space_protection#Pa... https://pax.grsecurity.net/docs/pageexec.txt https://pax.grsecurity.net/docs/pageexec.txt contrasted with: https://pax.grsecurity.net/docs/segmexec.txt https://pax.grsecurity.net/docs/segmexec.txt

wahern 5y ago

Publishing kernel patches is one thing; publishing an entire operating system distribution where everything runs properly out-of-the-box with those patches enabled by default is quite another. Yes, PaX kernel patches were published in October 2000, 3 years before OpenBSD made an official release with W^X (OpenBSD 3.3, May 2003). But without extensive changes in user space to ensure that data and code were separated in object files, you ended up with alot of complexity, and that complexity ultimately turned out to make PaX significantly less effective: https://lwn.net/Articles/126986/ https://lwn.net/Articles/126986/ Indeed, that's always been the problem with grsecurity patches in general--poor system integration which they've often tried to overcome with sophisticated (arguably overly sophisticated) methods. Neither grsecurity nor OpenBSD "invented" PaX/W^X. They were using pre-existing hardware features designed precisely for this type of capability, it just was never comprehensively employed by a major operating system because it required extensive changes not only to kernels but also, as it turns out, to userland.

knorker 5y ago
> Publishing kernel patches is one thing; publishing an entire operating system distribution where everything runs properly out-of-the-box with those patches enabled by default is quite another. That's exactly my point. That's why I find it so annoying that these articles say the wrong thing. > Neither grsecurity nor OpenBSD "invented" PaX/W^X. They were using pre-existing hardware features designed precisely for this type of capability, The first version of PaX predate the page table no-execute bit in x86 hardware, and I believe (eventually) W^X didn't require it either. So no it was not a matter of merely starting to use existing hardware capability. That's why it even was an invention in the first place. Everything got vastly easier once the page-level execute bit was launched in hardware. At the time, when OpenBSD was asked "why aren't you looking at what PaX did?", and they answered that "we don't care what others in the industry are doing". Which is a strange way to think you can create the best security. So Linux patches: 2000. OpenBSD: 2003. Windows: 2004. (not saying OpenBSD didn't do it better, because they don't care about binary compatability, making it easier) If OpenBSD had "invented" it, then how could microsoft possibly have launched it only one year later? Again, I do credit OpenBSD for being the first OS to do these things by default on an OS. But that is, as you said, is "quite another [thing]" from inventing it.
- wahern 5y ago
  PaX and W^X use segmentation on x86. x86 code segments were by design and definition non-writable--you couldn't write to any region in a code segment unless a writable data or stack segment overlapped the same region. This was a deliberate feature of the hardware that happened to go unused in favor of flat memory models in the most popular operating systems.
  - knorker 5y ago
    No. PaX has both SEGMEXEC and PAGEEXEC. PAGEEXEC does not use segmentation, and works without page-level HW support by using the split data/code TLB. https://en.wikipedia.org/wiki/Executable_space_protection#PaX https://en.wikipedia.org/wiki/Executable_space_protection#Pa... https://pax.grsecurity.net/docs/pageexec.txt https://pax.grsecurity.net/docs/pageexec.txt contrasted with: https://pax.grsecurity.net/docs/segmexec.txt https://pax.grsecurity.net/docs/segmexec.txt