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."

2 of 365 comments (clear)

  1. Re:Sacrfice useability? Nice idea , won't work. by Daniel_Staal · · Score: 5, Insightful

    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.
  2. Re:Slowdown? by ergo98 · · Score: 5, Insightful

    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?