[rc4algorithm]

No no no no no. When you do this, you are:

1) Reinventing malloc for no good reason 2) Opening yourself up to a whole world of security holes

See Bob Beck's talk on the first 30 days of LibreSSL. Heartbleed wouldn't have been nearly as catastrophic if OpenSSL just used the system memory allocator like normal people.

[nitrogen]

There are a few good reasons to reimplement malloc(), but of course it needs to be done very very carefully. For example, with a naive buddy list allocator it is (or was, in 2007) possible to more than triple allocation throughput vs. malloc(), but one loses many of malloc()'s security features.

[jeffreyrogers]

I don't understand how this could lead to a security hole any more easily than using malloc could. Can you give an example? The system memory allocator is using mmap internally anyways (on Linux and anywhere else using the Doug Lea allocator at least) and a simple region based allocator is only a couple dozen lines of code.

The semantics are simple as well:

    region create_region(size_t size);
    void * allocate(region *r, size_t size);
    void destroy_region(region *r);

Edit: also, you're not reinventing malloc for no good reason. A region based allocator is much faster, possibly at the expense of using more space than the system allocator (because you might reserve more space than you actually need).

[adrusi]

The point is that when you use malloc, an attacker exploiting a buffer overrun can't easily guess at the offset they need to find useful data. When you allocate everything in a big region, your process can be expected to read past the object bounds, so an attacker might be able to probe the address space (also the memory layout might be more deterministic). If they try to probe like that in a program that allocates with malloc, they'll just segfault the program.

[jeffreyrogers]

Yes, this is a reasonable objection.

[SamReidHughes]

If you want to count examples you're reasoning about this the wrong way. The question is what way leads to a higher probability of making a mistake, not the existence of discrete examples. Considering that one way, Valgrind works out of the box, but with your way, it doesn't, I think the answer to that question is quite clear. Even if there weren't tools like that, it is easier to read code and understand pointers' lifetimes when they're being handled individually, instead of having their lifetimes be part of some far-off region.

[jeffreyrogers]

The whole point of using regions is not to be worrying about pointer lifetimes. And you don't need Valgrind when you have regions since you aren't going to leak memory by forgetting to free something. Valgrind solves a problem that doesn't exist when you use regions.

If you're really worried that you'll leak an entire region worth of data just allocate the region with malloc instead of mmap and then use Valgrind to tell you what regions you aren't destroying.

[SamReidHughes]

Valgrind isn't for memory leaks, its main purpose is for catching out-of-bounds and uninitialized accesses.

[blt]

The risk is that you'll screw up and write a buggy allocator with a security hole.

Yes, if your program just needs to allocate lots of memory, do some computations, then exit, this approach works. But the programs where security is most critical do not usually follow that pattern.

[jeffreyrogers]

The code for this is so simple it would be hard to screw up. Plus you can just use obstacks[1] which pretty much provide the interface I was describing.

Look, I'm totally willing to accept that there might be flaws with this approach, but with the exception of adrusi, no one's objections have been all that reasonable. If there are legitimate objections (not just handwavy, oh, you'll probably implement the allocator wrong) I'd love to hear them. I use this pattern in my own code and I'll stop if there are legitimate flaws.

Also, Akamai released a patch for the OpenSSL allocator bug mentioned earlier. Guess what the patch used: mmaped regions.[2]

[1]: http://www.gnu.org/software/libc/manual/html_node/Obstacks.h...

[2]: http://thread.gmane.org/gmane.comp.encryption.openssl.user/5...

[z92]

Very good tip. Thank you. It looks like you are being opposed without a reason. Not everyone is writing encryption software in C.

[Sphax]

Would you happen to have some code online I can look at which use this technique ? I first saw Casey Muratori from https://handmadehero.org/ use an approach like this and used the same approach in a small project of mine. It worked well and was simple enough to implement.

[setpatchaddress]

Because you're going to have bugs. You don't need the extra performance, and you do need the extra safety. There is no good reason for you to do this in 2015, unless your system's malloc is broken. The exceptions to this rule know who they are.

[jeffreyrogers]

Yes, safety was the initial motivation. The advantage is that you free once and the semantics are more stack like. The performance is an additional benefit.

It is entirely possible to have no bugs in the <100 lines needed for this code, so I don't think the bug argument is valid. adrusi did raise a legitimate concern however.