3 ms·
Publishing kernel patches is one thing; publishing an entire operating system distribution where everything runs properly out-of-the-box with those patches enab
by 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 agoPaX 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 agoNo. 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