pcc wrote: > IIUC, the goal here is for the compiler to be able to apply e.g. pointer > authentication on fields of these structs automatically. It can't do so if > they are standard layout types, because then users are technically allowed to > poke into the binary representation of these types a bit too much. Did I get > that right?
That's right. For example, the standard would require that a standard-layout `std::unique_ptr<int>` has the same representation as `int *` (assuming the obvious implementation), and it was not considered practical to change the representation of all pointers for compatibility reasons. > Let's take for example std::shared_ptr. Before your patch, it is a standard > layout class. However, users technically can't take advantage of that, > because the only things that they would be allowed to do is inspect the > common initial subsequence of std::shared_ptr, use offsetof with it, or cast > a std::shared_ptr<...>* to its first member. None of that applies, because > all of its members are private (and reserved names anyway). Hence, making it > explicitly non-standard-layout should not be a breaking change for users. Do > I follow your line of thinking correctly? If the user knows the layout of std::shared_ptr, I think they could access the private fields via the common initial subsequence. In practice it seems highly unlikely that code would do this. So this could technically break the source level API, but that seems unlikely, and in the millions of lines of internal source code that I tested this on, I did not find any practical breakage caused by this. > Are there any other affordances provided by standard layout types that I > would have missed? Either in terms of API (i.e. what users can do with a SL > type), or ABI (e.g. the calling convention changes for SL types like it does > for trivial types)? It's important to have a solid grasp of this before we > can consider moving forward with this (and decide how to best do it). If this > e.g. breaks the ABI in any way, we'll need to have a completely different > conversation. Theoretically a change to standard-layout-ness for the standard types could break some ABI somewhere (the x86_64 and AArch64 psABIs don't mention standard layout, but maybe some other psABI does, and at least I suppose that some code somewhere could be doing things like making ABI-breaking decisions based on `std::is_standard_layout`), but this break only happens if the user opts into PFP (note that `_LIBCPP_MAYBE_FORCE_NONSTANDARD_LAYOUT` expands to nothing if PFP is disabled) so there will be no break for existing users. > Also, while we're talking about ABI, I assume that in your use case (which I > perhaps naively imagine to be applying ptrauth to struct fields), I guess > you'd be taking an ABI break to enable that new compiler feature, right? That's right, and I'd like to take advantage of the ABI break to make some things work better for PFP (like this standard-layout change) when it is enabled. PFP is still experimental, so we may consider making further changes to the libc++ ABI when it is enabled. > I do agree with what @philnik777 said in that other review -- I think we need > additional context and a RFC to understand what's your underlying plan, what > the constraints are and evaluate what is the impact to libc++. Sure. I already have https://discourse.llvm.org/t/rfc-structure-protection-a-family-of-uaf-mitigation-techniques/85555 which covers the feature as a whole (the "On standard layout types" section is most relevant for this PR) but I could try to write a separate RFC that focuses on the libc++ aspects. https://github.com/llvm/llvm-project/pull/151652 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
