It sounds a little bit like ElectricFence, although that project was more focused on finding memory bugs rather than security.
It would be good to consider which of these features is lightweight enough that it might be pulled into the glibc allocator. glibc is already doing good work with various hardening features (https://access.redhat.com/blogs/766093/posts/1976213). However I don't think they PROT_NONE internal data structures yet.
the main difference is that I'd be able to use IsoAlloc to actually write interesting features which allow me to isolate data inside a process depending on the security context (confine data to certain zones).
nice to get an additional introspection capability which allows verification for correctness during execution. This is a killer feature but I think the main purpose here is the isolation.
Performance overhead for this seems also reasonable considering what you get for it (security/sandboxing).
IsoAlloc author here. Thanks for reading the post and linking to the security properties. I plan to expand on those in an additional post and how I implemented them.
You're right that Electric Fence takes a different approach and is more geared towards finding bugs and isn't really suitable as a general purpose allocator. The easiest way to describe it is taking some allocations and placing them on their own page of memory, surrounding them with guard pages, and then setting the page PROT_NONE upon free so that any access results in a segfault. For a more modern attempt at this check out GWP ASAN which is doing something very similar but in Chrome across millions of installs https://chromium.googlesource.com/chromium/src.git/+/master/...
As for the allocator in glibc, a lot of its internal data structures either live on the same pages as user chunks or write meta data to free chunks. So using aggressive strategies like page permissions to protect that data is often not an option.
5 comments
[ 0.22 ms ] story [ 18.9 ms ] threadIt sounds a little bit like ElectricFence, although that project was more focused on finding memory bugs rather than security.
It would be good to consider which of these features is lightweight enough that it might be pulled into the glibc allocator. glibc is already doing good work with various hardening features (https://access.redhat.com/blogs/766093/posts/1976213). However I don't think they PROT_NONE internal data structures yet.
nice to get an additional introspection capability which allows verification for correctness during execution. This is a killer feature but I think the main purpose here is the isolation.
Performance overhead for this seems also reasonable considering what you get for it (security/sandboxing).
You're right that Electric Fence takes a different approach and is more geared towards finding bugs and isn't really suitable as a general purpose allocator. The easiest way to describe it is taking some allocations and placing them on their own page of memory, surrounding them with guard pages, and then setting the page PROT_NONE upon free so that any access results in a segfault. For a more modern attempt at this check out GWP ASAN which is doing something very similar but in Chrome across millions of installs https://chromium.googlesource.com/chromium/src.git/+/master/...
As for the allocator in glibc, a lot of its internal data structures either live on the same pages as user chunks or write meta data to free chunks. So using aggressive strategies like page permissions to protect that data is often not an option.