Slashdot Mirror
Heap Protection Mechanism
An anonymous reader writes "There's an article by Jason Miller on innovation in Unix that talks about OpenBSD's new heap protection mechanism as a major boon for security. Sounds like OpenBSD is going to be the first to support this new security method."
"What do you mean? Windows Vista will be more secure than Unix. j/k"
Just like...
Windows 95 was more secure than Windows 3.1
Windows 98 was more secure than Windows 95
Windows NT was much more secure than Windows 98
Windows 2000 was the mother of all security
Windows XP, this time we got it right
Windows XP SP2 this time we really really got it right, promise, cross my heart and hope to die
Windows 2003, most secure server OS ever built!
Windows VISTA, even better than the worlds best system ever built, this time ill put my mother up here on this 100 fot pole and if im wrong may she fall down into that pit of crocodiles!
Until i have a real life experience of good Windows security i will tend to think back and remember all the former promises that have gone down the drain. Today you expect Microsoft to promise things that arent really true.
HTTP/1.1 400
Actually, for OpenBSD, it will work. And has.
The reason is very simple: There will always be some applications where the security of the system is a paramount point. Where it does have to do with the application. OpenBSD caters directly to those people, and those applications.
Now, you are right, this means OpenBSD is likely to never get as large a following as Linux or even FreeBSD, but they honestly don't care. They are making a system that fits their goals, and security is among the top goals.
This actually allows security to spread: Once these changes are on a 'major' system, applications start to be ported to work with them, which means the changes can be ported to other systems.
OpenBSD is a security testing ground. If it's features get in your way, you use a different system. This won't be the first time that advice will have been applicable.
'Sensible' is a curse word.
Won't this crutch actually tempt people to write sloppy memory management because "the heap manager will catch it?"
Doesn't seem so. The new malloc and mmap behavior will tend to cause buggy memory allocation code to segfault rather than allowing various sorts of stupiness or nastiness.
I'm surprised that modern heaps still put writable data segments adjacent to executable code segments. Self-modifying code is rare enough that all code should be in read-only (except by privileged processes, like the kernel which sets it up and tears it down) segments, except when a process has privilege to write to its own code segment. Then its code segment should be a data segment, with other security features applied (that are too expensive to apply to every code segment). Generally then, segments are either writeable or executable. Data segments could still get overwritten, which could put unsafe values in unexpected variables (like "write to that file" instead of this file). But at least those insecure operations are limited to the operations programmed into the code, not arbitrary new code inserted into executables by buffer overflows.
After decades of these problems, and known techniques already applied in Computer Science, its surprising that we're only now seeing these techniques deployed in popular OS'es like OpenBSD. Hopefully the open nature of OpenBSD and other OSS OS'es will see them tested for winning strategies quickly, and widely adopted.
--
make install -not war
Who is "not giving back?"
Feel free to download all of their source code before complaining.
If you don't like it, don't use it, even though I'm sure you too benefited from some security fixes that originated with OpenBSD.
Malloc is slow. Per studies, 20-30% of CPU time wasted on memory management.
Interesting paper - thanks for the link.
However I find the conclusions given a bit dubious. For instance the claim that allocations are "free" is somewhat dubious - garbage collecting languages put all of the work on the back-end, giving the illusion of a free front-end (whereas non-GC languages put the hard work on the front-end). Yet for every object you create on the heap that is more work the heap walker has to do each GC to detect orphaned objects - a non-trivial task. It then has to free all of those objects, and because of the "free" allocation it has to move all of the objects and rebase every object pointer in the application. It doesn't take a genius to realize that is a signficiant task in an application of a real-world size.
I think the proof is in the empirical proof - how many high performance memory intensive Java applications are there?
PS: A quick look at some fast Java code. (It is a bit dated but gives you some idea what I am talking about.)
Hmm ... that's a little archaic. The page complains about Java performance in JDK 1.1, and appears to be based on a site (http://www.cs.cmu.edu/~jch/java/optimization.html ) that hasn't been updated since 1998.
I don't think the BSD allocator will reveal more software bugs unless the programmers have not tested with Electric Fence.
:)
The OpenBSD allocator already has revealed a number of software bugs (in X11, in ports, they lurk everywhere). Some of the bugs found were years old. Thats the point of the testing process in the OpenBSD release cycle.
I think you're missing the point behind the integration of these technologies into OpenBSD. The idea is that they are always on, with a performance hit that is acceptable that your day-to-day programs can be protected, and most crucially, used under them. Not sitting in a debug environment getting limited regressions and unit tests that the particular programmer felt like writing (and if I want that, I run it under Valgrind, which has a near-miraculous tendency to find lurking bugs).
And considering them in isolation is also dangerous. When you combine the address randomization, W^X, heap protection, propolice canaries and local variable re-ordering, you're left with a system that has accepted a reasonable performance hit in return for a large amount of protection against badly written code. Sprinkle in regular audits, timely releases every 6 months to keep our users up-to-date on stable systems, and a 'grep culture' to hunt down related bugs in the source tree when a bug does strike.
As others have pointed out, other "hero projects" have stuck bits and bobs into their respective distributions. But how many have had the discipline to follow through, maintain and integrate their patches, test the fallout and release a complete OS with thousands of third-party packages year after year... probably only Microsoft, but the first thing they do at the sign of incompatibility is to turn the protection off. Oh well