https://github.com/pcc updated https://github.com/llvm/llvm-project/pull/133538
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/pcc updated https://github.com/llvm/llvm-project/pull/133538
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -7538,6 +7538,14 @@ static bool IsEligibleForTrivialRelocation(Sema &SemaRef,
if (!SemaRef.IsCXXTriviallyRelocatableType(Field->getType()))
return false;
}
+
+ // FIXME: PFP should not affect trivial relocatability, instead it should
+ // affect the implementat
ojhunt wrote:
@pcc and I have been discussing this.
* The perf issues I was concerned about were predicated on access to a pointer
loaded from a field continuing to be checked after the original field load,
this is not the case (and in hindsight doing so would imply passing the pointer
as a p
ojhunt wrote:
> Hi Oliver, thanks for your comments! I'll address them below.
>
> > Thoughts:
> > This should be opt-in on a field or struct granularity, not just a global
> > behavior.
>
> This would certainly be easier if it were an opt-in behavior, as it would
> allow avoiding a substantia
@@ -362,6 +362,17 @@ class LangOptionsBase {
BKey
};
+ enum class PointerFieldProtectionKind {
pcc wrote:
I think that allowing this level of customization should be implemented as part
of the separate opt-in solution (e.g. it may be a property of the
@@ -441,6 +445,254 @@ bool
PreISelIntrinsicLowering::expandMemIntrinsicUses(Function &F) const {
return Changed;
}
+namespace {
+
+enum class PointerEncoding {
+ Rotate,
+ PACCopyable,
+ PACNonCopyable,
+};
+
+bool expandProtectedFieldPtr(Function &Intr) {
+ Module &M =
@@ -7538,6 +7538,14 @@ static bool IsEligibleForTrivialRelocation(Sema &SemaRef,
if (!SemaRef.IsCXXTriviallyRelocatableType(Field->getType()))
return false;
}
+
+ // FIXME: PFP should not affect trivial relocatability, instead it should
+ // affect the implementat
@@ -2268,13 +2293,22 @@ CodeGenFunction::EmitNullInitialization(Address
DestPtr, QualType Ty) {
// Get and call the appropriate llvm.memcpy overload.
Builder.CreateMemCpy(DestPtr, SrcPtr, SizeVal, false);
-return;
+ } else {
+// Otherwise, just memset the who
@@ -1319,14 +1319,66 @@ static llvm::Value
*CoerceIntOrPtrToIntOrPtr(llvm::Value *Val, llvm::Type *Ty,
/// This safely handles the case when the src type is smaller than the
/// destination type; in this situation the values of bits which not
/// present in the src are undefin
@@ -544,6 +544,7 @@ TYPE_TRAIT_2(__is_pointer_interconvertible_base_of,
IsPointerInterconvertibleBas
#include "clang/Basic/TransformTypeTraits.def"
// Clang-only C++ Type Traits
+TYPE_TRAIT_1(__has_non_relocatable_fields, HasNonRelocatableFields, KEYCXX)
ojhu
https://github.com/pcc commented:
Hi Oliver, thanks for your comments! I'll address them below.
> Thoughts:
>
> This should be opt-in on a field or struct granularity, not just a global
> behavior.
This would certainly be easier if it were an opt-in behavior, as it would allow
avoiding a sub
@@ -2201,6 +2215,22 @@ void CodeGenFunction::EmitCXXConstructorCall(
EmitTypeCheck(CodeGenFunction::TCK_ConstructorCall, Loc, This,
getContext().getRecordType(ClassDecl), CharUnits::Zero());
+ // When initializing an object that has pointer field protect
@@ -928,6 +936,11 @@ namespace {
if (PointerAuthQualifier Q = F->getType().getPointerAuth();
Q && Q.isAddressDiscriminated())
return false;
+ // Non-trivially-copyable fields with pointer field protection need to be
pcc wrote:
We c
https://github.com/pcc edited https://github.com/llvm/llvm-project/pull/133538
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -2268,13 +2293,22 @@ CodeGenFunction::EmitNullInitialization(Address
DestPtr, QualType Ty) {
// Get and call the appropriate llvm.memcpy overload.
Builder.CreateMemCpy(DestPtr, SrcPtr, SizeVal, false);
-return;
+ } else {
+// Otherwise, just memset the who
@@ -2976,7 +3006,15 @@ void CodeGenFunction::EmitForwardingCallToLambda(
QualType resultType = FPT->getReturnType();
ReturnValueSlot returnSlot;
if (!resultType->isVoidType() &&
- calleeFnInfo->getReturnInfo().getKind() == ABIArgInfo::Indirect &&
+ (calleeFnInfo
@@ -544,6 +544,7 @@ TYPE_TRAIT_2(__is_pointer_interconvertible_base_of,
IsPointerInterconvertibleBas
#include "clang/Basic/TransformTypeTraits.def"
// Clang-only C++ Type Traits
+TYPE_TRAIT_1(__has_non_relocatable_fields, HasNonRelocatableFields, KEYCXX)
pcc
@@ -7756,6 +7756,10 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
Args.addOptInFlag(CmdArgs, options::OPT_funique_source_file_names,
options::OPT_fno_unique_source_file_names);
+ if (!IsCudaDevice)
pcc wrote:
With CU
@@ -7538,6 +7538,14 @@ static bool IsEligibleForTrivialRelocation(Sema &SemaRef,
if (!SemaRef.IsCXXTriviallyRelocatableType(Field->getType()))
return false;
}
+
+ // FIXME: PFP should not affect trivial relocatability, instead it should
+ // affect the implementat
@@ -2513,6 +2513,12 @@ def CountedByOrNull : DeclOrTypeAttr {
let LangOpts = [COnly];
}
+def NoPointerFieldProtection : DeclOrTypeAttr {
pcc wrote:
There are numerous circumstances where the C++ ABI is distinct from the
platform ABI and is allowed to chang
@@ -441,6 +445,254 @@ bool
PreISelIntrinsicLowering::expandMemIntrinsicUses(Function &F) const {
return Changed;
}
+namespace {
+
+enum class PointerEncoding {
+ Rotate,
+ PACCopyable,
+ PACNonCopyable,
+};
+
+bool expandProtectedFieldPtr(Function &Intr) {
+ Module &M =
@@ -1415,6 +1469,52 @@ void CodeGenFunction::CreateCoercedStore(llvm::Value
*Src, Address Dst,
}
}
+ // Coercion directly through memory does not work if the structure has
pointer
+ // field protection because the struct passed by value has a different bit
+ // patt
@@ -3011,6 +3011,12 @@ defm experimental_omit_vtable_rtti :
BoolFOption<"experimental-omit-vtable-rtti"
NegFlag,
BothFlags<[], [CC1Option], " the RTTI component from virtual tables">>;
+def experimental_pointer_field_protection_EQ : Joined<["-"],
"fexperimental-pointer-f
@@ -544,6 +544,7 @@ TYPE_TRAIT_2(__is_pointer_interconvertible_base_of,
IsPointerInterconvertibleBas
#include "clang/Basic/TransformTypeTraits.def"
// Clang-only C++ Type Traits
+TYPE_TRAIT_1(__has_non_relocatable_fields, HasNonRelocatableFields, KEYCXX)
ojhu
@@ -1415,6 +1469,52 @@ void CodeGenFunction::CreateCoercedStore(llvm::Value
*Src, Address Dst,
}
}
+ // Coercion directly through memory does not work if the structure has
pointer
+ // field protection because the struct passed by value has a different bit
+ // patt
@@ -441,6 +445,254 @@ bool
PreISelIntrinsicLowering::expandMemIntrinsicUses(Function &F) const {
return Changed;
}
+namespace {
+
+enum class PointerEncoding {
+ Rotate,
+ PACCopyable,
+ PACNonCopyable,
+};
+
+bool expandProtectedFieldPtr(Function &Intr) {
+ Module &M =
https://github.com/ojhunt edited
https://github.com/llvm/llvm-project/pull/133538
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ojhunt commented:
unfortunately I really don't know enough about actual backend codegen to
comment on the actual codegen implementation here, but I think there's some
design issues with having the backend determine the discriminators rather than
having those selected in the
@@ -2201,6 +2215,22 @@ void CodeGenFunction::EmitCXXConstructorCall(
EmitTypeCheck(CodeGenFunction::TCK_ConstructorCall, Loc, This,
getContext().getRecordType(ClassDecl), CharUnits::Zero());
+ // When initializing an object that has pointer field protect
@@ -2268,13 +2293,22 @@ CodeGenFunction::EmitNullInitialization(Address
DestPtr, QualType Ty) {
// Get and call the appropriate llvm.memcpy overload.
Builder.CreateMemCpy(DestPtr, SrcPtr, SizeVal, false);
-return;
+ } else {
+// Otherwise, just memset the who
@@ -928,6 +936,11 @@ namespace {
if (PointerAuthQualifier Q = F->getType().getPointerAuth();
Q && Q.isAddressDiscriminated())
return false;
+ // Non-trivially-copyable fields with pointer field protection need to be
ojhunt wrote:
T
@@ -362,6 +362,17 @@ class LangOptionsBase {
BKey
};
+ enum class PointerFieldProtectionKind {
ojhunt wrote:
I'm not sure I like this being solely a global decision - it makes custom
allocators much harder, and it makes it hard for allocators that hav
@@ -2513,6 +2513,12 @@ def CountedByOrNull : DeclOrTypeAttr {
let LangOpts = [COnly];
}
+def NoPointerFieldProtection : DeclOrTypeAttr {
ojhunt wrote:
This an ABI break so I don't think it can reasonably an on by default for all
structs - we can already se
@@ -3011,6 +3011,12 @@ defm experimental_omit_vtable_rtti :
BoolFOption<"experimental-omit-vtable-rtti"
NegFlag,
BothFlags<[], [CC1Option], " the RTTI component from virtual tables">>;
+def experimental_pointer_field_protection_EQ : Joined<["-"],
"fexperimental-pointer-f
@@ -2976,7 +3006,15 @@ void CodeGenFunction::EmitForwardingCallToLambda(
QualType resultType = FPT->getReturnType();
ReturnValueSlot returnSlot;
if (!resultType->isVoidType() &&
- calleeFnInfo->getReturnInfo().getKind() == ABIArgInfo::Indirect &&
+ (calleeFnInfo
https://github.com/ojhunt requested changes to this pull request.
Thoughts:
This should be opt-in on a field or struct granularity, not just a global
behavior.
In the RFC I think you mentioned not applying PFP to C types, but I'm unsure
how you're deciding what is a C type?
There are a lot o
@@ -1319,14 +1319,66 @@ static llvm::Value
*CoerceIntOrPtrToIntOrPtr(llvm::Value *Val, llvm::Type *Ty,
/// This safely handles the case when the src type is smaller than the
/// destination type; in this situation the values of bits which not
/// present in the src are undefin
@@ -7538,6 +7538,14 @@ static bool IsEligibleForTrivialRelocation(Sema &SemaRef,
if (!SemaRef.IsCXXTriviallyRelocatableType(Field->getType()))
return false;
}
+
+ // FIXME: PFP should not affect trivial relocatability, instead it should
+ // affect the implementat
https://github.com/ojhunt edited
https://github.com/llvm/llvm-project/pull/133538
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/pcc updated https://github.com/llvm/llvm-project/pull/133538
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-serif,
https://github.com/pcc updated https://github.com/llvm/llvm-project/pull/133538
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-serif,
mordante wrote:
> > in libc++ we have a pre-commit CI so this feature should be tested in our
> > CI, if you need help with that, best reach out to us on Discord. However I
> > think we first need to look at how we can properly integrate this in libc++.
>
> Sure, I will get in touch once this
@@ -84,7 +84,7 @@ _LIBCPP_PUSH_MACROS
_LIBCPP_BEGIN_NAMESPACE_STD
template */>
-class _LIBCPP_TEMPLATE_VIS vector {
+class _LIBCPP_TEMPLATE_VIS vector _LIBCPP_MAYBE_FORCE_NONSTANDARD_LAYOUT {
pcc wrote:
The intent would be that the user builds libc++.a with
@@ -1215,6 +1215,29 @@ typedef __char32_t char32_t;
#define _LIBCPP_HAS_EXPLICIT_THIS_PARAMETER 0
# endif
+# if __has_feature(pointer_field_protection)
+// Force a class to be non-standard layout by giving it two bases with the same
+// type. This is useful when structur
@@ -1215,6 +1215,29 @@ typedef __char32_t char32_t;
#define _LIBCPP_HAS_EXPLICIT_THIS_PARAMETER 0
# endif
+# if __has_feature(pointer_field_protection)
pcc wrote:
Makes sense, will do.
https://github.com/llvm/llvm-project/pull/133538
__
https://github.com/pcc commented:
> in libc++ we have a pre-commit CI so this feature should be tested in our CI,
> if you need help with that, best reach out to us on Discord. However I think
> we first need to look at how we can properly integrate this in libc++.
Sure, I will get in touch on
https://github.com/pcc edited https://github.com/llvm/llvm-project/pull/133538
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1215,6 +1215,29 @@ typedef __char32_t char32_t;
#define _LIBCPP_HAS_EXPLICIT_THIS_PARAMETER 0
# endif
+# if __has_feature(pointer_field_protection)
mordante wrote:
Since this feature is an ABI break, it will cause ODR violations to these
structs. I
https://github.com/mordante requested changes to this pull request.
Some comments from libc++'s perspective:
- As you mentioned you need more tests.
- I think the current approach with a header only libc++ change approach will
not work due to ABI changes. See review comment for `std::vector`.
-
https://github.com/mordante edited
https://github.com/llvm/llvm-project/pull/133538
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1215,6 +1215,29 @@ typedef __char32_t char32_t;
#define _LIBCPP_HAS_EXPLICIT_THIS_PARAMETER 0
# endif
+# if __has_feature(pointer_field_protection)
+// Force a class to be non-standard layout by giving it two bases with the same
+// type. This is useful when structur
@@ -84,7 +84,7 @@ _LIBCPP_PUSH_MACROS
_LIBCPP_BEGIN_NAMESPACE_STD
template */>
-class _LIBCPP_TEMPLATE_VIS vector {
+class _LIBCPP_TEMPLATE_VIS vector _LIBCPP_MAYBE_FORCE_NONSTANDARD_LAYOUT {
mordante wrote:
`std::vector` is used in the libc++ dylib across t
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff ee0ee253d617aa4cddfe5216f93365645579b54d
3bdbe711b5f937d564e1883ec94e1c5ecbd87750 --e
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Peter Collingbourne (pcc)
Changes
Pointer field protection is a use-after-free vulnerability
mitigation that works by changing how data structures' pointer
fields are stored in memory. For more information, see the RFC:
https://disco
github-actions[bot] wrote:
:warning: undef deprecator found issues in your code. :warning:
You can test this locally with the following command:
``bash
git diff -U0 --pickaxe-regex -S
'([^a-zA-Z0-9#_-]undef[^a-zA-Z0-9_-]|UndefValue::get)'
ee0ee253d617aa4cddfe5216f93365645579b54d
https://github.com/pcc created https://github.com/llvm/llvm-project/pull/133538
Pointer field protection is a use-after-free vulnerability
mitigation that works by changing how data structures' pointer
fields are stored in memory. For more information, see the RFC:
https://discourse.llvm.org/t/rf
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: Peter Collingbourne (pcc)
Changes
Pointer field protection is a use-after-free vulnerability
mitigation that works by changing how data structures' pointer
fields are stored in memory. For more information, see the RFC:
https://disc
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Peter Collingbourne (pcc)
Changes
Pointer field protection is a use-after-free vulnerability
mitigation that works by changing how data structures' pointer
fields are stored in memory. For more information, see the RFC:
https://discourse.ll
59 matches
Mail list logo
