* Implement tracking full slabs and large allocations
This adds an additional SeqSet that is used to track all the fully
used slabs and large allocations. This gives more chances to
detect memory leaks, and additionally catch some more UAF failures
where the object is not recycled.
* Make slabmeta track a slab interior pointer
Use the head of the free list builder to track an interior pointer to
the slab. This is unused unless the list contains something.
Hence, we can use this to represent an interior pointer to the slab and
report more accurate leaks.
* clangformat
* clangtidy
* clangtidy
* Clang tidy again.
* Fixing provenance.
* Clangformat
* Clang tidy.
* Add assert for sanity
* Make reinterpret_cast more descriptive.
Add an operation to get a tag free pointer from an address_t, and use it
* Clangformat
* CR
* Fix calculation of number of allocations.
* Fix calculation of number of allocations.
* Fix test
As with CTest, but without the full machinery thereof. This facilitates
package builders to use the usual build targets (all, install) without
needing to build the test programs if they're just going to get dropped
on the floor.
This will serve as the granularity with which we store authority
pointers in the (forthcoming) authmap, so 4K is almost surely too small.
16M is, admittedly, chosen out of a hat.
To date, we've had exactly one kind of Pagemap and it held exactly one
type of thing, a descendant of class MetaEntryBase.
PagemapRegisterRange tacitly assumed that the Pagemap (adapter) it
interacted would therefore store entries that could have .set_boundary()
called on them. But in general there's no requirement that this be
true; Pagemaps are generic data structures.
To enable reuse of the PagemapRegisterRange machinery more generally,
change the type of Pagemap::register_range() to take a pointer (rather
than an address) and move the MetaEntryBase-specific functionality to
the backend_helpers/pagemap adapter.
Instead, take a template parameter for the no-args init() method, so
that randomization can be disabled on StrictProvenance architectures
(CHERI), where we don't expect it to be useful, even when snmalloc is
being built to be otherwise paranoid.
Catch callsites up.
More directly ensure that a "basic" pagemap's type matches its
"concrete" pagemap parameter's entry type. Absent this check, getting
this wrong won't be detected until even further along in template code
generation (when considering a method that sees the mismatch).
* Add indirect range
The ranges currently either completely own the parent range, or it is
a static and thus completely shared.
The indirect range allows sharing without it being global.
Co-authored-by: Nathaniel Filardo <nfilardo@microsoft.com>
* [NFC] Simplify static constexpr inline
`constexpr` => `inline`
and when not in a class scope
`constexpr` => `static`
This PR removes the redundant use of `inline` and `static`. It also
prefers
`static constexpr`
over
`constexpr static`
* Extend pagemap test
Check for possible overlap between heap and pagemap, but writing and
reading the heap.
* Return unalign memory from the pagemap
This commit allows the pagemap to return unaligned range of memory. This
means that bump allocation of multiple pagemaps doesn't
waste as much space.
* Fail more abruptly if the bounds are not exact.
* Move bounding from Pool into Backend.
This commit makes the rounding and the bounding occur in the same
function.
* Enable smallbuddyrange to handle larger requests
The smallbuddy can now pass the larger requests up the range chain if
it cannot satisfy it itself.
* Test larger requests for meta-data.
Pull a part the locking from the static range. This enables
locking to be added to a range directly, and does not require
it to be made static. This is useful in cases where the source
of memory is shared between threads, but not static. I.e. there
are multiple instances of the same type.
StrictProvenance architectures are likely to impose additional alignment
requirements on their pointer-sized loads and stores. On the other
hand, we must use pointer-sized loads and stores wherever possible to
ensure achieve copy. Add a StrictProvenance-aware memcpy architecture
implementation.
Thanks to Matt for suggesting the trick of avoiding even thinking about
capability operations in the too-misaligned 16-31 byte cases as well as
other helpful suggestions.
Co-authored-by: Matthew Parkinson <mattpark@microsoft.com>
