Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CHERI: Use another pagemap for arena pointers #578

Merged
merged 16 commits into from
Dec 14, 2022

Conversation

nwf-msr
Copy link
Contributor

@nwf-msr nwf-msr commented Dec 12, 2022

Holding the arena pointers in slab metadata invites tricky problems in the presence of misbehaving clients and the current mix-in approach means that the metadata isn't a standard layout type. Here's a first stab at using another Pagemap for the arena pointers in modern snmalloc. We'd tried this approach before, but it feels much less bolted-on now, thanks to the "build-yourself-a-malloc kit" design that snmalloc has grown into.

This is, unfortunately, very slightly (0.2%) slower when used to run SPEC CPU2006 471.omnetpp (more or less a malloc performance benchmark) on the Morello cluster nodes, at the moment. There may be a straightforward optimization I've missed; can investigate.

For review, probably best to proceed commit-by-commit rather than all at once, and you can ignore the #577 at the bottom. As is not uncommon for my PRs, we may decide to pull some things off the bottom of this one to merge while the rest bakes a bit more.

@nwf-msr nwf-msr requested a review from mjp41 December 12, 2022 14:16
@mjp41
Copy link
Member

mjp41 commented Dec 13, 2022

Awesome, LGTM. I think we can simplify FrontendMetadata and BackendMetadata, and push all needs for custom meta-data to use a different pagemap. That works for this use case, and Monza. I guess we should think about

  • memory tagging
  • other per-allocation tagging (used bit potentially for prompt UAF detection, or an alternative revocation mechanism.)

Those are the use cases where I have considered a custom meta-data.

@@ -7,6 +7,9 @@ namespace snmalloc
{
/**
* Protect the ParentRange with a spin lock.
*
* Accesses via the ancestor() mechanism will bypass the lock and so
* should be used only where the resulting data races are acceptable.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if there is a way to add some API that requires something to be explicitly set to pass a lock range with an ancestor call.

These functions depend only on the PAL and so can live lower down the
stack.
Separate out the pagemap datastructure (ds/pagemap.h) from the backend
adapter shim (backend_helpers/pagemap.h).
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).
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.
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.
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.
@nwf-msr nwf-msr merged commit 74becb8 into microsoft:main Dec 14, 2022
@nwf-msr nwf-msr deleted the 202212-authmap branch December 14, 2022 17:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants