Skip to content

Prepare libcxx and libcxxabi for pointer field protection. #151651

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.

Sign up for GitHub

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

Open
pcc wants to merge 9 commits into
base: users/pcc/spr/main.prepare-libcxx-and-libcxxabi-for-pointer-field-protection
Choose a base branch
from
+24 −5
Open

Prepare libcxx and libcxxabi for pointer field protection. #151651

Show file tree
Hide file tree
Changes from 6 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
1d63bc5
[𝘀𝗽𝗿] initial version
pcc Aug 1, 2025
f0e1b0a
Rebase
pcc Aug 2, 2025
13e4502
Switch to new attribute
pcc Sep 5, 2025
d8b6925
Address review comments
pcc Sep 11, 2025
4f82ef8
Rebase
pcc Sep 11, 2025
a7305bc
Rebase
pcc Oct 9, 2025
7820ec4
Address review comments
pcc Oct 10, 2025
d215060
Rebase
pcc Nov 26, 2025
94d9f30
Format
pcc Nov 26, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 20 additions & 1 deletion libcxx/include/__config
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -484,8 +484,21 @@ typedef __char32_t char32_t;
# define _LIBCPP_EXCEPTIONS_SIG e
# endif

# if !_LIBCPP_HAS_EXCEPTIONS
# define _LIBCPP_EXCEPTIONS_SIG n
# else
# define _LIBCPP_EXCEPTIONS_SIG e
# endif

# if defined(__POINTER_FIELD_PROTECTION__)
# define _LIBCPP_PFP_SIG p
# else
# define _LIBCPP_PFP_SIG
# endif
Copy link
Contributor

@philnik777 philnik777 Sep 10, 2025

Choose a reason for hiding this comment

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

My understanding is that pfp changes the layout of certain types? Why should there be an ABI tag for it?

Copy link
Contributor Author

@pcc pcc Sep 10, 2025

Choose a reason for hiding this comment

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

Yes, the in-memory pointer format changes so it's effectively a layout (ABI) change. Therefore we need an ABI tag change to detect/prevent linking against mismatching ABIs. This was requested by @mordante in #133538.

Copy link
Contributor

@philnik777 philnik777 Oct 10, 2025

Choose a reason for hiding this comment

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

That's only for ceses where we want different TUs to link together. Since PFP changes the layout of types that's not something we want users to do, which in turn means that we don't want to make it visible in the ABI tag. We should instead change the whole inline namespace.

Copy link
Contributor Author

@pcc pcc Oct 10, 2025

Choose a reason for hiding this comment

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

Okay, I removed this logic and added CMake logic to modify the namespace name if PFP is enabled.


# define _LIBCPP_ODR_SIGNATURE \
_LIBCPP_CONCAT(_LIBCPP_CONCAT(_LIBCPP_HARDENING_SIG, _LIBCPP_EXCEPTIONS_SIG), _LIBCPP_VERSION)
_LIBCPP_CONCAT(_LIBCPP_CONCAT(_LIBCPP_CONCAT(_LIBCPP_HARDENING_SIG, _LIBCPP_EXCEPTIONS_SIG), _LIBCPP_PFP_SIG), \
_LIBCPP_VERSION)

// This macro marks a symbol as being hidden from libc++'s ABI. This is achieved
// on two levels:
Expand Down Expand Up @@ -1263,6 +1276,12 @@ typedef __char32_t char32_t;
# define _LIBCPP_HAS_EXPLICIT_THIS_PARAMETER 0
# endif

# if __has_cpp_attribute(_Clang::__no_field_protection__)
# define _LIBCPP_NO_PFP [[_Clang::__no_field_protection__]]
# else
# define _LIBCPP_NO_PFP
# endif
Comment on lines +1070 to +1074
Copy link
Member

@ldionne ldionne Dec 4, 2025

Choose a reason for hiding this comment

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

I'd suggest _LIBCPP_DISABLE_PFP or even _LIBCPP_DISABLE_POINTER_FIELD_PROTECTION. _LIBCPP_NO_PFP feels like like a yes-no macro, not an attribute macro.

Copy link
Contributor Author

@pcc pcc Dec 4, 2025

Choose a reason for hiding this comment

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

Will do


#endif // __cplusplus

#endif // _LIBCPP___CONFIG
3 changes: 3 additions & 0 deletions libcxx/include/__type_traits/is_trivially_relocatable.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,10 +34,13 @@ template <class _Tp, class = void>
struct __libcpp_is_trivially_relocatable : is_trivially_copyable<_Tp> {};
#endif

// __trivially_relocatable on libc++'s builtin types does not currently return the right answer with PFP.
Copy link
Member

@ldionne ldionne Dec 4, 2025

Choose a reason for hiding this comment

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

Suggested change
// __trivially_relocatable on libc++'s builtin types does not currently return the right answer with PFP.
// __trivially_relocatable on libc++'s builtin types does not currently return the right answer with PFP.

What do you mean by "libc++ builtin types"? Do you mean libc++ types like std::string & friends? We are currently not using Clang's notion of trivially-relocatable for anything, so I'm not certain we need to disable this when PFP is enabled. IMO we need to take a look at each individual type who advertises __trivially_relocatable and check whether that's fine with PFP.

Copy link
Contributor Author

@pcc pcc Dec 4, 2025

Choose a reason for hiding this comment

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

I looked at all the types and I think they would all be non-trivially-relocatable with PFP because they can all contain pointer fields.

We could surround each using __trivially_relocatable with an #ifndef __POINTER_FIELD_PROTECTION__, but that could make it easier to accidentally introduce a PFP-incompatible type, which would hopefully be detectable via testing, but it's possible that the tests will not trigger the bug. Disabling it like this seemed like the most robust approach.

Copy link
Member

@ldionne ldionne Dec 5, 2025

Choose a reason for hiding this comment

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

I feel like what really makes the most sense is to disable it on a per type basis. But perhaps we can extract the fundamental property that makes these types non-TR with PFP into something general in a way that doesn't require an explicit #if __POINTER_FIELD_PROTECTION__ at each place where we determine TR.

So I guess my question is: what is the fundamental property that makes these types non-TR when PFP is enabled?

#if !defined(__POINTER_FIELD_PROTECTION__)
template <class _Tp>
struct __libcpp_is_trivially_relocatable<_Tp,
__enable_if_t<is_same<_Tp, typename _Tp::__trivially_relocatable>::value> >
: true_type {};
#endif

_LIBCPP_END_NAMESPACE_STD

Expand Down
2 changes: 1 addition & 1 deletion libcxx/include/typeinfo
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -300,7 +300,7 @@ class _LIBCPP_EXPORTED_FROM_ABI _LIBCPP_TYPE_INFO_VTABLE_POINTER_AUTH type_info
protected:
typedef __type_info_implementations::__impl __impl;

__impl::__type_name_t __type_name;
_LIBCPP_NO_PFP __impl::__type_name_t __type_name;
Copy link
Member

@ldionne ldionne Dec 4, 2025

Choose a reason for hiding this comment

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

To reiterate my comment on the RFC, I would much rather we teach Clang how to generate the right thing here. I understand this might reduce the amount of work needed in Clang, but at the end of the day the PFP implementation in Clang will be more complete and more robust if it can handle this out of the box -- even if the actual security benefits are marginal.

The same comment holds for the changes in private_typeinfo.h -- that would actually have the nice effect of not requiring any changes to libc++abi.

Copy link
Contributor Author

@pcc pcc Dec 4, 2025

Choose a reason for hiding this comment

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

That would have the following downsides:

  1. More complexity in the compiler for no real benefit.
  2. The names of the fields would become part of the ABI, i.e. all ABI implementations would need to use the same names in order to avoid mismatches with clang-generated code. Fortunately it looks like gcc is using the same field names here, so maybe that doesn't matter.
  3. Would no longer be able to link a PFP libc++ and a non-PFP libc++ into the same program, because the libc++abi implementations would expect different ABIs (the PFP side would expect these fields to be signed).

That being said, I don't feel strongly about it, so if it doesn't take too much time I guess I don't mind doing it.

Copy link
Member

@ldionne ldionne Dec 5, 2025

Choose a reason for hiding this comment

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

  1. More complexity in the compiler for no real benefit.

Whether there is a "real benefit" is subjective, though. Not having to think about PFP in libc++abi is a very real (and valuable) benefit from my perspective (but perhaps not from someone else's perspective).

  1. The names of the fields would become part of the ABI, i.e. all ABI implementations would need to use the same names in order to avoid mismatches with clang-generated code. Fortunately it looks like gcc is using the same field names here, so maybe that doesn't matter.

Can you explain why that's the case? Where/why is the name of the field relevant when PFP is enabled? That's probably obvious when you know PFP but I'm not seeing it.

  1. Would no longer be able to link a PFP libc++ and a non-PFP libc++ into the same program, because the libc++abi implementations would expect different ABIs (the PFP side would expect these fields to be signed).

IIUC, you are implying that right now, we could link both a PFP libc++ and a non-PFP libc++ into the same program without issues because they use a different inline namespace, and libc++abi.dylib doesn't have an inline namespace. So IIUC what you're saying is that you could use pfp-libc++.dylib, nonpfp-libc++.dylib and libc++abi.dylib (which would be PFP-agnostic) into the same program. Is that the idea? My first reaction to this is that it seems like a very fragile setup.

That being said, I don't feel strongly about it, so if it doesn't take too much time I guess I don't mind doing it.

Let's finish this discussion first!


_LIBCPP_HIDE_FROM_ABI explicit type_info(const char* __n) : __type_name(__impl::__string_to_type_name(__n)) {}

Expand Down
6 changes: 6 additions & 0 deletions libcxxabi/include/__cxxabi_config.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -109,4 +109,10 @@
# define _LIBCXXABI_NOEXCEPT noexcept
#endif

#if defined(__POINTER_FIELD_PROTECTION__)
# define _LIBCXXABI_NO_PFP [[_Clang::__no_field_protection__]]
#else
# define _LIBCXXABI_NO_PFP
#endif

#endif // ____CXXABI_CONFIG_H
6 changes: 3 additions & 3 deletions libcxxabi/src/private_typeinfo.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -145,7 +145,7 @@ class _LIBCXXABI_TYPE_VIS __class_type_info : public __shim_type_info {
// Has one non-virtual public base class at offset zero
class _LIBCXXABI_TYPE_VIS __si_class_type_info : public __class_type_info {
public:
const __class_type_info *__base_type;
_LIBCXXABI_NO_PFP const __class_type_info *__base_type;

_LIBCXXABI_HIDDEN virtual ~__si_class_type_info();

Expand Down Expand Up @@ -204,7 +204,7 @@ class _LIBCXXABI_TYPE_VIS __vmi_class_type_info : public __class_type_info {
class _LIBCXXABI_TYPE_VIS __pbase_type_info : public __shim_type_info {
public:
unsigned int __flags;
const __shim_type_info *__pointee;
_LIBCXXABI_NO_PFP const __shim_type_info *__pointee;

enum __masks {
__const_mask = 0x1,
Expand Down Expand Up @@ -245,7 +245,7 @@ class _LIBCXXABI_TYPE_VIS __pointer_type_info : public __pbase_type_info {
class _LIBCXXABI_TYPE_VIS __pointer_to_member_type_info
: public __pbase_type_info {
public:
const __class_type_info *__context;
_LIBCXXABI_NO_PFP const __class_type_info *__context;

_LIBCXXABI_HIDDEN virtual ~__pointer_to_member_type_info();
_LIBCXXABI_HIDDEN virtual bool can_catch(const __shim_type_info *,
Expand Down
Loading