RFC: libc++ and pointer field protection

Runtimes C++
3

Thanks for the RFC. I think most of the aspects discussed here make sense, but I have some comments:

  • Trivial relocation: I think it’s OK to temporarily disable libc++'s emulation of TR until the C++26 feature is stable and landed, at which point the compiler builtin should handle PFP fields properly.
  • Forcing non-standard layout on some types: I don’t think that’s the right way to handle that. Forcing types to be non standard-layout in order to achieve PFP protection on their fields is a roundabout way of doing things. Instead, here are some ideas:
    • Could we change the compiler’s rule for PFPing fields such that that standard-layout types with only private fields still get PFP protection? The libc++ types we want to enable PFP for likely all fall in that category (of having only private members). However, that would make changing a field from private to public be ABI breaking when PFP is enabled, which would be an unusual and surprising ABI particularity of that mode.
    • We could mark those fields with an attribute that makes them PFP protected even if the type is standard layout. However it’s not 100% clear on what fields we should put that attribute, and in theory we would end up annotating almost all pointer fields of all types with that attribute, which doesn’t scale. I still think that would be the best solution here: we can document the macro that applies the attribute with a guideline about when it’s needed, and it looks like such an attribute is already part of your plans (based on skimming the original RFC).
  • For RTTI fields: Do we lose anything significant by leaving those fields be PFP protected? Unless there is a fundamental reason to avoid that, I would just use the default rules and not try to opt-out these fields.

Generally speaking: We already have a bit of custom code to control arm64e pointer authentication related things, for example _LIBCPP_TYPE_INFO_VTABLE_POINTER_AUTH in <typeinfo>. I would like to better understand the relationship between PFP and pointer authentication, especially as it relates to its interaction with the library. Can we handle both in the same way, have attributes that pertain to both, etc? I think it’s important for our sanity to avoid a proliferation of similar-but-different security-related extensions that all require different annotations and have different characteristics. When I say “our sanity”, I mean primarily libc++'s but I really think that extends to arbitrary end users who might try to use these extensions in a similar way: if we can’t find a simple way to handle them uniformly for libc++, I have concerns that end users would be just as much if not more confused than ourselves.