3 ms·

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

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

SamReidHughes 11y ago
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 11y ago
  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 11y ago
    Valgrind isn't for memory leaks, its main purpose is for catching out-of-bounds and uninitialized accesses.
adrusi 11y ago
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 11y ago
  Yes, this is a reasonable objection.
setpatchaddress 11y ago
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 11y ago
  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.
blt 11y ago
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 11y ago
  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.html http://www.gnu.org/software/libc/manual/html_node/Obstacks.h... [2]: http://thread.gmane.org/gmane.comp.encryption.openssl.user/51243 http://thread.gmane.org/gmane.comp.encryption.openssl.user/5...
  - z92 11y ago
    Very good tip. Thank you. It looks like you are being opposed without a reason. Not everyone is writing encryption software in C.
Sphax 11y ago
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/ 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.

SamReidHughes 11y ago

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 11y ago
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 11y ago
  Valgrind isn't for memory leaks, its main purpose is for catching out-of-bounds and uninitialized accesses.

adrusi 11y ago

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 11y ago
Yes, this is a reasonable objection.

setpatchaddress 11y ago

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 11y ago
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.

blt 11y ago

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 11y ago
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.html http://www.gnu.org/software/libc/manual/html_node/Obstacks.h... [2]: http://thread.gmane.org/gmane.comp.encryption.openssl.user/51243 http://thread.gmane.org/gmane.comp.encryption.openssl.user/5...
- z92 11y ago
  Very good tip. Thank you. It looks like you are being opposed without a reason. Not everyone is writing encryption software in C.

Sphax 11y ago

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