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."
When the application is finished with the memory, it sends a FAX to the local electronics recycling facility who sends out a tech to remove the DIMMs and melt them down into whatever.
Using this method of heap memory allocation (I call it "ACAlloc" for "Anonymous Coward Alloc" has been 100% effective and I have NEVER had a heap overflow exploit in any of my code.
Yes, it's slow, but I am secure.
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.
You mean the Data Execute Protection from Microsoft? OpenBSD has had that for a long time already, only they named it w^x.
This new feature from OpenBSD is the use of guard pages and the immediate freeing of memory. In essence this means that both bad programming and exploit attempts are much more likely to result in a core dump then some unidentifiable and non reproducible corruption or a working exploit. Many people consider that a good thing because it will result in bugs being found in userland applications that would have otherwise stayed unnoticed. So even if you don't use OpenBSD yourself this is helping your system becomming more secure and better. And if you are running OpenBSD there is o need to worry too much about the stability of this feature, it was actually enabled shortly after the 3.7 release and has been in every snapshot on the way to 3.8.
And I have to agree with the author that the best thing is that we get all the goods without ever having to switch them on!
Ho hum.
y /j-jtp09275.html
http://www-128.ibm.com/developerworks/java/librar
Malloc is slow. Per studies, 20-30% of CPU time wasted on memory management.
I haven't seen that level of retardation in JVM's since... oh... 1996?
But yeah, keep thinking you can do it better. Whatever. In the meanwhile, the rest of the world moves on.
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?
2005 self would counter with, "Yeah, the pointers will be bigger than they used to be, but you progam in high-level languages now, so you don't ever worry about that. It's the compiler's problem."
1987 Sloppy would say, "But I'm going go write a compiler!"
2005 Sloppy would say, "You fuckwit, you never got anywhere on that project. You barely even started it. Too much time fucking around with graphics and genetics."
1987 Sloppy would say, "But, but, it's not fair! Segmentation is an x86 thing. Everyone knows that in the future, we'll all be using 68k. 68k doesn't do segmentation."
2005 Sloppy would sigh.
1987 Sloppy would say, "Oh come on. There's no way people are still using x86 in the 21st century, or even in the 1990s. No fucking way."
2005 Sloppy would just shrug. There's nothing to do in a situation like this. There's nothing you can say. They'll never believe you.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.