Conversation

Replying to

It will also be possible to use memory tagging for large allocations, but those are already guaranteed to have randomly sized guard regions (at least 1 guard page) on each side and there's a virtual memory quarantine guaranteeing that address space isn't used again for a while.

1

For large allocations it would be used solely as a probabilistic mitigation for accesses between allocations and to a lesser extent probabilistic use-after-free mitigation. They already get replaced with a PROT_NONE mapping via MAP_FIXED on free and that region is quarantined.

2

Replying to

I really like #FreeBSD's MAP_GUARD implementation for guard pages. It's used in #bhyve to protect the VM's address space from the host's perspective. MAP_GUARD is essentially PROT_NONE on steroids. It prevents growable segments (ie, MAP_STACK) from expanding into the region.

1

1

Replying to

On Linux, MAP_STACK is a no-op and secondary stack mappings are just a contiguous, static mapping like other mmap mappings so it doesn't really matter. The main thread stack is a special case and has a properly enforced gap that's not a PROT_NONE region so it can't grow into one.

2

Replying to

and

The enforced gap is a special reserved area rather than an actual normal mapping. Secondary stacks are just a mapping made by the libc pthread_create implementation (or the caller, if they provide their own stack) with a guard region. I improved that in my past libc hardening.

1

Replying to

and

In my previous Bionic hardening, I added randomly sized guard regions on both ends similar to how I handle large allocations in the hardened allocator along with randomizing the stack pointer within the initial page to a certain extent up to a limit like 2% of available space.

1

Replying to

That's something I need to look into for HardenedBSD again: random-sized MAP_GUARD stack guard pages for per-thread stacks.

1

Replying to

You can see how it's implemented: github.com/AndroidHardeni It's only tricky for aligned allocations (not applicable to stacks) and isn't that complex. Here's where it chooses the random guard size: github.com/AndroidHardeni It's stored alongside size: github.com/AndroidHardeni

1

1

Replying to

and

I meant to link to pages.c rather than memory.c: github.com/AndroidHardeni The whole purpose of pages.c / pages.h is to provide a wrapper around memory.c / memory.h implementing support for guard pages in a mostly transparent way. It's not entirely transparent due to realloc.

1

1

Replying to

and

Since realloc actually has to be aware of how the guard pages work for the efficient approaches to large allocation shrinking, growth and moving pages to a new location with the mapping already reserved via MREMAP_MAYMOVE|MREMAP_FIXED. Those are just optimized fast paths though.

2

Replying to

and

So this realloc section is essentially part of the implementation of guard pages too and is by far the most complex part of it: github.com/AndroidHardeni It's quite tricky to implement some of this with proper handling for out-of-memory errors. It can barely use MREMAP_MAYMOVE.

5:54 PM · Feb 4, 2019Twitter Web Client

Replying to

and

It has to actually allocate a new mapping in the usual way to provide it with guard pages, and then move the non-guard pages to the new inner portion via MREMAP_MAYMOVE|MREMAP_FIXED. It essentially uses it as an optimized memcpy and falls back to memcpy if that system call fails.

1

Replying to

and

On a system without MREMAP_MAYMOVE, that portion would just be disabled so it falls through to the standard handling at the bottom: github.com/AndroidHardeni There's another use of mremap without MREMAP_MAYMOVE for in-place growth. MAP_FIXED_NOREPLACE would also work for that.

1

Show replies