Shouldn't they be at the top of the address space then overruns would never hit them as they'd start below or does it not work like that.

Or you can put in a memory area with unmapped sections on both sides if you are paranoid.

IIRC openbsd's malloc does something like that by default, so every bit of data gets its own protected address space... and then the openssl guys built their own malloc without that feature, to get better performance :(

True.. I wonder if any specs/certifications actually require something like that. Typically I mostly use tricks like that to track down bugs, but there's nothing wrong with using it in production for something like a single key/cert alloc. It becomes a bit unwieldy if you have lots of things to protect. (Especially on machines with 64k pages :))

Well it seems like Akamai were doing exactly that. If you have lots I would go multi process though.

Someone else who uses Powerpc?

The bug is reading 64k from x -> x+64k. You'd want the key as low as possible in memory so the chance of the heap implementation allocating a request below it (thus allowing the +64k to overlap into the key) is next to nil.

So if your key was at an address less than x the bug would never read it, was my point. So I guess that means you'd have to force the UDP datagram payload to be stored high as that dictates what x is?