-
Notifications
You must be signed in to change notification settings - Fork 15.4k
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.
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
base: users/pcc/spr/main.prepare-libcxx-and-libcxxabi-for-pointer-field-protection
Are you sure you want to change the base?
Changes from 1 commit
1d63bc5
f0e1b0a
13e4502
d8b6925
4f82ef8
a7305bc
7820ec4
d215060
94d9f30
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That would have the following downsides:
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.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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).
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.
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
Let's finish this discussion first! |
||
|
|
||
| _LIBCPP_HIDE_FROM_ABI explicit type_info(const char* __n) : __type_name(__impl::__string_to_type_name(__n)) {} | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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_relocatableand check whether that's fine with PFP.There was a problem hiding this comment.
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_relocatablewith 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.There was a problem hiding this comment.
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?