[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
https://github.com/ahmedbougacha closed https://github.com/llvm/llvm-project/pull/97647 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Implement type/address discrimination of type_info vtable. (PR #99726)
https://github.com/ahmedbougacha closed https://github.com/llvm/llvm-project/pull/99726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Implement type/address discrimination of type_info vtable. (PR #99726)
https://github.com/ahmedbougacha ready_for_review https://github.com/llvm/llvm-project/pull/99726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Implement type/address discrimination of type_info vtable. (PR #99726)
https://github.com/ahmedbougacha updated
https://github.com/llvm/llvm-project/pull/99726
>From f46421f8e0349f65f07ab3bd822e179bf983439f Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Wed, 17 Jul 2024 16:18:41 -0700
Subject: [PATCH 1/2] [clang] Implement type/address discrimination of
type_info vtable.
We want to be able to support full type and address discrimination
of type_info on targets that don't have existing ABI compatibility
constraints.
This patch does not enable such behavior on any platform, it just
adds the necessary machinery.
In clang we add a new commandline argument to control the type_info
vtable ABI:
-fptrauth-type-info-vtable-pointer-discrimination
and a feature flag to allow source level detection of the ABI:
__has_feature(ptrauth_type_info_vtable_pointer_discrimination)
---
clang/include/clang/Basic/Features.def| 1 +
clang/include/clang/Basic/LangOptions.def | 1 +
.../include/clang/Basic/PointerAuthOptions.h | 5 ++
clang/include/clang/Driver/Options.td | 2 +
clang/lib/Frontend/CompilerInvocation.cpp | 17 +++-
.../CodeGenCXX/ptrauth-type-info-vtable.cpp | 87 +++
6 files changed, 111 insertions(+), 2 deletions(-)
create mode 100644 clang/test/CodeGenCXX/ptrauth-type-info-vtable.cpp
diff --git a/clang/include/clang/Basic/Features.def
b/clang/include/clang/Basic/Features.def
index 2f864ff1c0edf..14572bc0407fc 100644
--- a/clang/include/clang/Basic/Features.def
+++ b/clang/include/clang/Basic/Features.def
@@ -108,6 +108,7 @@ FEATURE(ptrauth_calls, LangOpts.PointerAuthCalls)
FEATURE(ptrauth_returns, LangOpts.PointerAuthReturns)
FEATURE(ptrauth_vtable_pointer_address_discrimination,
LangOpts.PointerAuthVTPtrAddressDiscrimination)
FEATURE(ptrauth_vtable_pointer_type_discrimination,
LangOpts.PointerAuthVTPtrTypeDiscrimination)
+FEATURE(ptrauth_type_info_vtable_pointer_discrimination,
LangOpts.PointerAuthTypeInfoVTPtrDiscrimination)
FEATURE(ptrauth_member_function_pointer_type_discrimination,
LangOpts.PointerAuthCalls)
FEATURE(ptrauth_init_fini, LangOpts.PointerAuthInitFini)
FEATURE(ptrauth_function_pointer_type_discrimination,
LangOpts.PointerAuthFunctionTypeDiscrimination)
diff --git a/clang/include/clang/Basic/LangOptions.def
b/clang/include/clang/Basic/LangOptions.def
index a6f36b23f07dc..8b09049b5cb97 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -168,6 +168,7 @@ LANGOPT(PointerAuthReturns, 1, 0, "return pointer
authentication")
LANGOPT(PointerAuthAuthTraps, 1, 0, "pointer authentication failure traps")
LANGOPT(PointerAuthVTPtrAddressDiscrimination, 1, 0, "incorporate address
discrimination in authenticated vtable pointers")
LANGOPT(PointerAuthVTPtrTypeDiscrimination, 1, 0, "incorporate type
discrimination in authenticated vtable pointers")
+LANGOPT(PointerAuthTypeInfoVTPtrDiscrimination, 1, 0, "incorporate type and
address discrimination in authenticated vtable pointers for std::type_info")
LANGOPT(PointerAuthInitFini, 1, 0, "sign function pointers in init/fini
arrays")
BENIGN_LANGOPT(PointerAuthFunctionTypeDiscrimination, 1, 0,
"Use type discrimination when signing function pointers")
diff --git a/clang/include/clang/Basic/PointerAuthOptions.h
b/clang/include/clang/Basic/PointerAuthOptions.h
index 197d63642ca6d..6153209410843 100644
--- a/clang/include/clang/Basic/PointerAuthOptions.h
+++ b/clang/include/clang/Basic/PointerAuthOptions.h
@@ -25,6 +25,11 @@ namespace clang {
constexpr unsigned PointerAuthKeyNone = -1;
+/// Constant discriminator for std::type_info vtable pointers: 0xB1EA/45546
+/// The value is ptrauth_string_discriminator("_ZTVSt9type_info"), i.e.,
+/// the vtable type discriminator for classes derived from std::type_info.
+constexpr uint16_t StdTypeInfoVTablePointerConstantDiscrimination = 0xB1EA;
+
class PointerAuthSchema {
public:
enum class Kind : unsigned {
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index 9c6cebd77ff0a..70dab1b16094d 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4249,6 +4249,8 @@ defm ptrauth_vtable_pointer_address_discrimination :
OptInCC1FFlag<"ptrauth-vtable-pointer-address-discrimination", "Enable
address discrimination of vtable pointers">;
defm ptrauth_vtable_pointer_type_discrimination :
OptInCC1FFlag<"ptrauth-vtable-pointer-type-discrimination", "Enable type
discrimination of vtable pointers">;
+defm ptrauth_type_info_vtable_pointer_discrimination :
+ OptInCC1FFlag<"ptrauth-type-info-vtable-pointer-discrimination", "Enable
type and address discrimination of vtable pointer of std::type_info">;
defm ptrauth_init_fini : OptInCC1FFlag<"ptrauth-init-fini", "Enable signing of
function pointers in init/fini arrays">;
defm ptrauth_function_pointer_type_discrimination :
OptInCC1FFlag<"ptrauth-function-pointer-type-discrimination",
"Enable type
[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
https://github.com/ahmedbougacha updated
https://github.com/llvm/llvm-project/pull/97647
>From 519570896c82887a5dd878fcc16f884857d4fce3 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Tue, 12 Mar 2024 14:40:17 -0700
Subject: [PATCH 1/5] [AArch64][PAC] Sign block addresses used in indirectbr.
Enabled in clang using:
-fptrauth-indirect-gotos
and at the IR level using function attribute:
"ptrauth-indirect-gotos"
Signing uses IA and a per-function integer discriminator.
The discriminator isn't ABI-visible, and is currently:
ptrauth_string_discriminator(" blockaddress")
A sufficiently sophisticated frontend could benefit from
per-indirectbr discrimination, which would need additional
machinery, such as allowing "ptrauth" bundles on indirectbr.
For our purposes, the simple scheme above is sufficient.
---
clang/include/clang/Basic/Features.def| 1 +
clang/include/clang/Basic/LangOptions.def | 1 +
.../include/clang/Basic/PointerAuthOptions.h | 3 +
clang/include/clang/Driver/Options.td | 2 +
clang/lib/CodeGen/CodeGenFunction.cpp | 2 +
clang/lib/Driver/ToolChains/Clang.cpp | 3 +
clang/lib/Frontend/CompilerInvocation.cpp | 6 +-
.../CodeGen/ptrauth-function-attributes.c | 5 +
llvm/docs/PointerAuth.md | 24
llvm/include/llvm/CodeGen/AsmPrinter.h| 3 +
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp| 6 +-
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | 35 +-
llvm/lib/Target/AArch64/AArch64FastISel.cpp | 4 +
.../Target/AArch64/AArch64ISelLowering.cpp| 53 -
llvm/lib/Target/AArch64/AArch64ISelLowering.h | 1 +
llvm/lib/Target/AArch64/AArch64InstrInfo.td | 18 +++
llvm/lib/Target/AArch64/AArch64Subtarget.cpp | 11 ++
llvm/lib/Target/AArch64/AArch64Subtarget.h| 9 ++
.../GISel/AArch64InstructionSelector.cpp | 26 +
.../CodeGen/AArch64/ptrauth-indirectbr.ll | 106 ++
20 files changed, 308 insertions(+), 11 deletions(-)
create mode 100644 llvm/test/CodeGen/AArch64/ptrauth-indirectbr.ll
diff --git a/clang/include/clang/Basic/Features.def
b/clang/include/clang/Basic/Features.def
index 53f410d3cb4bd..cf800afe08557 100644
--- a/clang/include/clang/Basic/Features.def
+++ b/clang/include/clang/Basic/Features.def
@@ -108,6 +108,7 @@ FEATURE(ptrauth_calls, LangOpts.PointerAuthCalls)
FEATURE(ptrauth_returns, LangOpts.PointerAuthReturns)
FEATURE(ptrauth_vtable_pointer_address_discrimination,
LangOpts.PointerAuthVTPtrAddressDiscrimination)
FEATURE(ptrauth_vtable_pointer_type_discrimination,
LangOpts.PointerAuthVTPtrTypeDiscrimination)
+FEATURE(ptrauth_indirect_gotos, LangOpts.PointerAuthIndirectGotos)
FEATURE(ptrauth_member_function_pointer_type_discrimination,
LangOpts.PointerAuthCalls)
FEATURE(ptrauth_init_fini, LangOpts.PointerAuthInitFini)
EXTENSION(swiftcc,
diff --git a/clang/include/clang/Basic/LangOptions.def
b/clang/include/clang/Basic/LangOptions.def
index 491759e2fcdbb..bdf77a5b35208 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -165,6 +165,7 @@ LANGOPT(ExperimentalLibrary, 1, 0, "enable unstable and
experimental library fea
LANGOPT(PointerAuthIntrinsics, 1, 0, "pointer authentication intrinsics")
LANGOPT(PointerAuthCalls , 1, 0, "function pointer authentication")
LANGOPT(PointerAuthReturns, 1, 0, "return pointer authentication")
+LANGOPT(PointerAuthIndirectGotos, 1, 0, "indirect gotos pointer
authentication")
LANGOPT(PointerAuthAuthTraps, 1, 0, "pointer authentication failure traps")
LANGOPT(PointerAuthVTPtrAddressDiscrimination, 1, 0, "incorporate address
discrimination in authenticated vtable pointers")
LANGOPT(PointerAuthVTPtrTypeDiscrimination, 1, 0, "incorporate type
discrimination in authenticated vtable pointers")
diff --git a/clang/include/clang/Basic/PointerAuthOptions.h
b/clang/include/clang/Basic/PointerAuthOptions.h
index 197d63642ca6d..2711639dbe299 100644
--- a/clang/include/clang/Basic/PointerAuthOptions.h
+++ b/clang/include/clang/Basic/PointerAuthOptions.h
@@ -154,6 +154,9 @@ class PointerAuthSchema {
};
struct PointerAuthOptions {
+ /// Do indirect goto label addresses need to be authenticated?
+ bool IndirectGotos = false;
+
/// The ABI for C function pointers.
PointerAuthSchema FunctionPointers;
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index 58ca6f2bea9e4..791b7261ddbda 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4228,6 +4228,8 @@ defm ptrauth_vtable_pointer_address_discrimination :
defm ptrauth_vtable_pointer_type_discrimination :
OptInCC1FFlag<"ptrauth-vtable-pointer-type-discrimination", "Enable type
discrimination of vtable pointers">;
defm ptrauth_init_fini : OptInCC1FFlag<"ptrauth-init-fini", "Enable signing of
function pointers in init/fini arrays">;
+defm ptrauth_indirect_gotos :
[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
@@ -1789,6 +1789,9 @@ void Clang::AddAArch64TargetArgs(const ArgList , options::OPT_fno_ptrauth_vtable_pointer_type_discrimination); Args.addOptInFlag(CmdArgs, options::OPT_fptrauth_init_fini, options::OPT_fno_ptrauth_init_fini); + ahmedbougacha wrote: The whitespaces help differentiate the different classes of fptrauth features (here frontendy vs backendy); TBH we should probably have more, not less https://github.com/llvm/llvm-project/pull/97647 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
@@ -412,6 +412,15 @@ class AArch64Subtarget final : public
AArch64GenSubtargetInfo {
/// Choose a method of checking LR before performing a tail call.
AArch64PAuth::AuthCheckMethod getAuthenticatedLRCheckMethod() const;
+ /// Compute the integer discriminator for a given BlockAddress constant, if
+ /// blockaddress signing is enabled (using function attribute
+ /// "ptrauth-indirect-gotos").
ahmedbougacha wrote:
I added `IfNeeded` to make the function name more explicit?
https://github.com/llvm/llvm-project/pull/97647
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
@@ -10685,6 +10689,26 @@ SDValue AArch64TargetLowering::LowerBR_JT(SDValue Op,
return DAG.getNode(ISD::BRIND, DL, MVT::Other, JTInfo, SDValue(Dest, 0));
}
+SDValue AArch64TargetLowering::LowerBRIND(SDValue Op, SelectionDAG ) const
{
+ MachineFunction = DAG.getMachineFunction();
+ std::optional BADisc =
+ Subtarget->getPtrAuthBlockAddressDiscriminator(MF.getFunction());
+ if (!BADisc)
+return SDValue();
+
+ SDLoc DL(Op);
+ SDValue Chain = Op.getOperand(0);
+ SDValue Dest = Op.getOperand(1);
+
+ SDValue Disc = DAG.getTargetConstant(*BADisc, DL, MVT::i64);
+ SDValue Key = DAG.getTargetConstant(AArch64PACKey::IA, DL, MVT::i32);
+ SDValue AddrDisc = DAG.getRegister(AArch64::XZR, MVT::i64);
+
+ SDNode *BrA = DAG.getMachineNode(AArch64::BRA, DL, MVT::Other,
ahmedbougacha wrote:
Interesting, that explains it. I'd rather have the BR_JT survive as a BR_JT
(or really, an AArch64 BR_JT that's analogous to ISD::BRIND, so that we can
still do what we do on JumpTableDests), but that's a more serious change for
the whole backend; let's do it separately. For now checking the target seems
iffy but probably workable
https://github.com/llvm/llvm-project/pull/97647
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
@@ -0,0 +1,106 @@ +; RUN: llc -mtriple arm64e-apple-darwin \ ahmedbougacha wrote: It's not too bad; switched https://github.com/llvm/llvm-project/pull/97647 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
https://github.com/ahmedbougacha updated
https://github.com/llvm/llvm-project/pull/97647
>From 519570896c82887a5dd878fcc16f884857d4fce3 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Tue, 12 Mar 2024 14:40:17 -0700
Subject: [PATCH 1/3] [AArch64][PAC] Sign block addresses used in indirectbr.
Enabled in clang using:
-fptrauth-indirect-gotos
and at the IR level using function attribute:
"ptrauth-indirect-gotos"
Signing uses IA and a per-function integer discriminator.
The discriminator isn't ABI-visible, and is currently:
ptrauth_string_discriminator(" blockaddress")
A sufficiently sophisticated frontend could benefit from
per-indirectbr discrimination, which would need additional
machinery, such as allowing "ptrauth" bundles on indirectbr.
For our purposes, the simple scheme above is sufficient.
---
clang/include/clang/Basic/Features.def| 1 +
clang/include/clang/Basic/LangOptions.def | 1 +
.../include/clang/Basic/PointerAuthOptions.h | 3 +
clang/include/clang/Driver/Options.td | 2 +
clang/lib/CodeGen/CodeGenFunction.cpp | 2 +
clang/lib/Driver/ToolChains/Clang.cpp | 3 +
clang/lib/Frontend/CompilerInvocation.cpp | 6 +-
.../CodeGen/ptrauth-function-attributes.c | 5 +
llvm/docs/PointerAuth.md | 24
llvm/include/llvm/CodeGen/AsmPrinter.h| 3 +
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp| 6 +-
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | 35 +-
llvm/lib/Target/AArch64/AArch64FastISel.cpp | 4 +
.../Target/AArch64/AArch64ISelLowering.cpp| 53 -
llvm/lib/Target/AArch64/AArch64ISelLowering.h | 1 +
llvm/lib/Target/AArch64/AArch64InstrInfo.td | 18 +++
llvm/lib/Target/AArch64/AArch64Subtarget.cpp | 11 ++
llvm/lib/Target/AArch64/AArch64Subtarget.h| 9 ++
.../GISel/AArch64InstructionSelector.cpp | 26 +
.../CodeGen/AArch64/ptrauth-indirectbr.ll | 106 ++
20 files changed, 308 insertions(+), 11 deletions(-)
create mode 100644 llvm/test/CodeGen/AArch64/ptrauth-indirectbr.ll
diff --git a/clang/include/clang/Basic/Features.def
b/clang/include/clang/Basic/Features.def
index 53f410d3cb4bd..cf800afe08557 100644
--- a/clang/include/clang/Basic/Features.def
+++ b/clang/include/clang/Basic/Features.def
@@ -108,6 +108,7 @@ FEATURE(ptrauth_calls, LangOpts.PointerAuthCalls)
FEATURE(ptrauth_returns, LangOpts.PointerAuthReturns)
FEATURE(ptrauth_vtable_pointer_address_discrimination,
LangOpts.PointerAuthVTPtrAddressDiscrimination)
FEATURE(ptrauth_vtable_pointer_type_discrimination,
LangOpts.PointerAuthVTPtrTypeDiscrimination)
+FEATURE(ptrauth_indirect_gotos, LangOpts.PointerAuthIndirectGotos)
FEATURE(ptrauth_member_function_pointer_type_discrimination,
LangOpts.PointerAuthCalls)
FEATURE(ptrauth_init_fini, LangOpts.PointerAuthInitFini)
EXTENSION(swiftcc,
diff --git a/clang/include/clang/Basic/LangOptions.def
b/clang/include/clang/Basic/LangOptions.def
index 491759e2fcdbb..bdf77a5b35208 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -165,6 +165,7 @@ LANGOPT(ExperimentalLibrary, 1, 0, "enable unstable and
experimental library fea
LANGOPT(PointerAuthIntrinsics, 1, 0, "pointer authentication intrinsics")
LANGOPT(PointerAuthCalls , 1, 0, "function pointer authentication")
LANGOPT(PointerAuthReturns, 1, 0, "return pointer authentication")
+LANGOPT(PointerAuthIndirectGotos, 1, 0, "indirect gotos pointer
authentication")
LANGOPT(PointerAuthAuthTraps, 1, 0, "pointer authentication failure traps")
LANGOPT(PointerAuthVTPtrAddressDiscrimination, 1, 0, "incorporate address
discrimination in authenticated vtable pointers")
LANGOPT(PointerAuthVTPtrTypeDiscrimination, 1, 0, "incorporate type
discrimination in authenticated vtable pointers")
diff --git a/clang/include/clang/Basic/PointerAuthOptions.h
b/clang/include/clang/Basic/PointerAuthOptions.h
index 197d63642ca6d..2711639dbe299 100644
--- a/clang/include/clang/Basic/PointerAuthOptions.h
+++ b/clang/include/clang/Basic/PointerAuthOptions.h
@@ -154,6 +154,9 @@ class PointerAuthSchema {
};
struct PointerAuthOptions {
+ /// Do indirect goto label addresses need to be authenticated?
+ bool IndirectGotos = false;
+
/// The ABI for C function pointers.
PointerAuthSchema FunctionPointers;
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index 58ca6f2bea9e4..791b7261ddbda 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4228,6 +4228,8 @@ defm ptrauth_vtable_pointer_address_discrimination :
defm ptrauth_vtable_pointer_type_discrimination :
OptInCC1FFlag<"ptrauth-vtable-pointer-type-discrimination", "Enable type
discrimination of vtable pointers">;
defm ptrauth_init_fini : OptInCC1FFlag<"ptrauth-init-fini", "Enable signing of
function pointers in init/fini arrays">;
+defm ptrauth_indirect_gotos :
[clang] [clang] Implement type/address discrimination of type_info vtable. (PR #99726)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/99726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Implement type/address discrimination of type_info vtable. (PR #99726)
https://github.com/ahmedbougacha created
https://github.com/llvm/llvm-project/pull/99726
We want to be able to support full type and address discrimination of type_info
on targets that don't have existing ABI compatibility constraints.
This patch does not enable such behavior on any platform, it just adds the
necessary machinery.
In clang we add a new commandline argument to control the type_info vtable ABI:
```
-fptrauth-type-info-vtable-pointer-discrimination
```
and a feature flag to allow source level detection of the ABI:
```
__has_feature(ptrauth_type_info_vtable_pointer_discrimination)
```
>From f46421f8e0349f65f07ab3bd822e179bf983439f Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Wed, 17 Jul 2024 16:18:41 -0700
Subject: [PATCH] [clang] Implement type/address discrimination of type_info
vtable.
We want to be able to support full type and address discrimination
of type_info on targets that don't have existing ABI compatibility
constraints.
This patch does not enable such behavior on any platform, it just
adds the necessary machinery.
In clang we add a new commandline argument to control the type_info
vtable ABI:
-fptrauth-type-info-vtable-pointer-discrimination
and a feature flag to allow source level detection of the ABI:
__has_feature(ptrauth_type_info_vtable_pointer_discrimination)
---
clang/include/clang/Basic/Features.def| 1 +
clang/include/clang/Basic/LangOptions.def | 1 +
.../include/clang/Basic/PointerAuthOptions.h | 5 ++
clang/include/clang/Driver/Options.td | 2 +
clang/lib/Frontend/CompilerInvocation.cpp | 17 +++-
.../CodeGenCXX/ptrauth-type-info-vtable.cpp | 87 +++
6 files changed, 111 insertions(+), 2 deletions(-)
create mode 100644 clang/test/CodeGenCXX/ptrauth-type-info-vtable.cpp
diff --git a/clang/include/clang/Basic/Features.def
b/clang/include/clang/Basic/Features.def
index 2f864ff1c0edf..14572bc0407fc 100644
--- a/clang/include/clang/Basic/Features.def
+++ b/clang/include/clang/Basic/Features.def
@@ -108,6 +108,7 @@ FEATURE(ptrauth_calls, LangOpts.PointerAuthCalls)
FEATURE(ptrauth_returns, LangOpts.PointerAuthReturns)
FEATURE(ptrauth_vtable_pointer_address_discrimination,
LangOpts.PointerAuthVTPtrAddressDiscrimination)
FEATURE(ptrauth_vtable_pointer_type_discrimination,
LangOpts.PointerAuthVTPtrTypeDiscrimination)
+FEATURE(ptrauth_type_info_vtable_pointer_discrimination,
LangOpts.PointerAuthTypeInfoVTPtrDiscrimination)
FEATURE(ptrauth_member_function_pointer_type_discrimination,
LangOpts.PointerAuthCalls)
FEATURE(ptrauth_init_fini, LangOpts.PointerAuthInitFini)
FEATURE(ptrauth_function_pointer_type_discrimination,
LangOpts.PointerAuthFunctionTypeDiscrimination)
diff --git a/clang/include/clang/Basic/LangOptions.def
b/clang/include/clang/Basic/LangOptions.def
index a6f36b23f07dc..8b09049b5cb97 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -168,6 +168,7 @@ LANGOPT(PointerAuthReturns, 1, 0, "return pointer
authentication")
LANGOPT(PointerAuthAuthTraps, 1, 0, "pointer authentication failure traps")
LANGOPT(PointerAuthVTPtrAddressDiscrimination, 1, 0, "incorporate address
discrimination in authenticated vtable pointers")
LANGOPT(PointerAuthVTPtrTypeDiscrimination, 1, 0, "incorporate type
discrimination in authenticated vtable pointers")
+LANGOPT(PointerAuthTypeInfoVTPtrDiscrimination, 1, 0, "incorporate type and
address discrimination in authenticated vtable pointers for std::type_info")
LANGOPT(PointerAuthInitFini, 1, 0, "sign function pointers in init/fini
arrays")
BENIGN_LANGOPT(PointerAuthFunctionTypeDiscrimination, 1, 0,
"Use type discrimination when signing function pointers")
diff --git a/clang/include/clang/Basic/PointerAuthOptions.h
b/clang/include/clang/Basic/PointerAuthOptions.h
index 197d63642ca6d..6153209410843 100644
--- a/clang/include/clang/Basic/PointerAuthOptions.h
+++ b/clang/include/clang/Basic/PointerAuthOptions.h
@@ -25,6 +25,11 @@ namespace clang {
constexpr unsigned PointerAuthKeyNone = -1;
+/// Constant discriminator for std::type_info vtable pointers: 0xB1EA/45546
+/// The value is ptrauth_string_discriminator("_ZTVSt9type_info"), i.e.,
+/// the vtable type discriminator for classes derived from std::type_info.
+constexpr uint16_t StdTypeInfoVTablePointerConstantDiscrimination = 0xB1EA;
+
class PointerAuthSchema {
public:
enum class Kind : unsigned {
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index 9c6cebd77ff0a..70dab1b16094d 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4249,6 +4249,8 @@ defm ptrauth_vtable_pointer_address_discrimination :
OptInCC1FFlag<"ptrauth-vtable-pointer-address-discrimination", "Enable
address discrimination of vtable pointers">;
defm ptrauth_vtable_pointer_type_discrimination :
[clang] [clang] Ensure pointers passed to runtime support functions are correctly signed (PR #98276)
https://github.com/ahmedbougacha closed https://github.com/llvm/llvm-project/pull/98276 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
ahmedbougacha wrote: > The difference should be not be signed IMO as stated above. We discussed this in the sync-up, but for the record I don't think we can get away with not signing and nothing else. It defeats the purpose of signing these in the first place: an arbitrary write becomes a branch to an arbitrary destination. One alternative would be to sign the difference, though we would want to have a specific way for people to write it to make it predictable (single expression, 64-bit result; maybe explicitly as a builtin). Doesn't help existing code, but there's already a high adoption cost for all of these ptrauth changes, this seems almost trivial in comparison ;) A radically different solution could be to lower the blockaddresses without signing, then turn the goto into a checked switch. That allows substitution, but that's already the case for signed blockaddresses. That would easily work with real block addresses, but the switch would look nasty. If we used some dense numbering of the address-taken blocks, and lowered `blockaddress()` into that number, then the switch becomes a simple jump table, and the only check needed is a range check. So we'd pretty much end up with the "hardened" jump-table from #97666. Either way this could still be relatively expensive, and pushes the cost from address materialization to dispatch, which seems like the worst tradeoff for anyone using indirect goto.. So I'm not sure I would want to adopt this for MachO, but I'm happy to help and review if folks want to implement this. Thankfully this isn't ABI visible (beyond the usual problems with code looking at the values) so either way we can replace this entirely in the future. In the meantime, for this PR, I'll look into more actionable errors for the unencodable constant expressions, and the single-expression difference, when we can diagnose it. But at the end of the day they'll still be errors. https://github.com/llvm/llvm-project/pull/97647 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
https://github.com/ahmedbougacha ready_for_review https://github.com/llvm/llvm-project/pull/97647 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
ahmedbougacha wrote:
> Please make sure you have a testcase for computing the difference between two
> blockaddresses (void g(int*); int f() { static int x = &&
> A:g();B:return x; }). Not sure how you should handle that case.
Oh yeah, we can't handle that at all, I don't think! The best we can do is
probably to declare it disallowed and try to diagnose it in the frontend as
best we can.. I don't think we ever looked into that, I'll give it a try
https://github.com/llvm/llvm-project/pull/97647
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
https://github.com/ahmedbougacha updated
https://github.com/llvm/llvm-project/pull/97647
>From 519570896c82887a5dd878fcc16f884857d4fce3 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Tue, 12 Mar 2024 14:40:17 -0700
Subject: [PATCH] [AArch64][PAC] Sign block addresses used in indirectbr.
Enabled in clang using:
-fptrauth-indirect-gotos
and at the IR level using function attribute:
"ptrauth-indirect-gotos"
Signing uses IA and a per-function integer discriminator.
The discriminator isn't ABI-visible, and is currently:
ptrauth_string_discriminator(" blockaddress")
A sufficiently sophisticated frontend could benefit from
per-indirectbr discrimination, which would need additional
machinery, such as allowing "ptrauth" bundles on indirectbr.
For our purposes, the simple scheme above is sufficient.
---
clang/include/clang/Basic/Features.def| 1 +
clang/include/clang/Basic/LangOptions.def | 1 +
.../include/clang/Basic/PointerAuthOptions.h | 3 +
clang/include/clang/Driver/Options.td | 2 +
clang/lib/CodeGen/CodeGenFunction.cpp | 2 +
clang/lib/Driver/ToolChains/Clang.cpp | 3 +
clang/lib/Frontend/CompilerInvocation.cpp | 6 +-
.../CodeGen/ptrauth-function-attributes.c | 5 +
llvm/docs/PointerAuth.md | 24
llvm/include/llvm/CodeGen/AsmPrinter.h| 3 +
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp| 6 +-
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | 35 +-
llvm/lib/Target/AArch64/AArch64FastISel.cpp | 4 +
.../Target/AArch64/AArch64ISelLowering.cpp| 53 -
llvm/lib/Target/AArch64/AArch64ISelLowering.h | 1 +
llvm/lib/Target/AArch64/AArch64InstrInfo.td | 18 +++
llvm/lib/Target/AArch64/AArch64Subtarget.cpp | 11 ++
llvm/lib/Target/AArch64/AArch64Subtarget.h| 9 ++
.../GISel/AArch64InstructionSelector.cpp | 26 +
.../CodeGen/AArch64/ptrauth-indirectbr.ll | 106 ++
20 files changed, 308 insertions(+), 11 deletions(-)
create mode 100644 llvm/test/CodeGen/AArch64/ptrauth-indirectbr.ll
diff --git a/clang/include/clang/Basic/Features.def
b/clang/include/clang/Basic/Features.def
index 53f410d3cb4bd..cf800afe08557 100644
--- a/clang/include/clang/Basic/Features.def
+++ b/clang/include/clang/Basic/Features.def
@@ -108,6 +108,7 @@ FEATURE(ptrauth_calls, LangOpts.PointerAuthCalls)
FEATURE(ptrauth_returns, LangOpts.PointerAuthReturns)
FEATURE(ptrauth_vtable_pointer_address_discrimination,
LangOpts.PointerAuthVTPtrAddressDiscrimination)
FEATURE(ptrauth_vtable_pointer_type_discrimination,
LangOpts.PointerAuthVTPtrTypeDiscrimination)
+FEATURE(ptrauth_indirect_gotos, LangOpts.PointerAuthIndirectGotos)
FEATURE(ptrauth_member_function_pointer_type_discrimination,
LangOpts.PointerAuthCalls)
FEATURE(ptrauth_init_fini, LangOpts.PointerAuthInitFini)
EXTENSION(swiftcc,
diff --git a/clang/include/clang/Basic/LangOptions.def
b/clang/include/clang/Basic/LangOptions.def
index 491759e2fcdbb..bdf77a5b35208 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -165,6 +165,7 @@ LANGOPT(ExperimentalLibrary, 1, 0, "enable unstable and
experimental library fea
LANGOPT(PointerAuthIntrinsics, 1, 0, "pointer authentication intrinsics")
LANGOPT(PointerAuthCalls , 1, 0, "function pointer authentication")
LANGOPT(PointerAuthReturns, 1, 0, "return pointer authentication")
+LANGOPT(PointerAuthIndirectGotos, 1, 0, "indirect gotos pointer
authentication")
LANGOPT(PointerAuthAuthTraps, 1, 0, "pointer authentication failure traps")
LANGOPT(PointerAuthVTPtrAddressDiscrimination, 1, 0, "incorporate address
discrimination in authenticated vtable pointers")
LANGOPT(PointerAuthVTPtrTypeDiscrimination, 1, 0, "incorporate type
discrimination in authenticated vtable pointers")
diff --git a/clang/include/clang/Basic/PointerAuthOptions.h
b/clang/include/clang/Basic/PointerAuthOptions.h
index 197d63642ca6d..2711639dbe299 100644
--- a/clang/include/clang/Basic/PointerAuthOptions.h
+++ b/clang/include/clang/Basic/PointerAuthOptions.h
@@ -154,6 +154,9 @@ class PointerAuthSchema {
};
struct PointerAuthOptions {
+ /// Do indirect goto label addresses need to be authenticated?
+ bool IndirectGotos = false;
+
/// The ABI for C function pointers.
PointerAuthSchema FunctionPointers;
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index 58ca6f2bea9e4..791b7261ddbda 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4228,6 +4228,8 @@ defm ptrauth_vtable_pointer_address_discrimination :
defm ptrauth_vtable_pointer_type_discrimination :
OptInCC1FFlag<"ptrauth-vtable-pointer-type-discrimination", "Enable type
discrimination of vtable pointers">;
defm ptrauth_init_fini : OptInCC1FFlag<"ptrauth-init-fini", "Enable signing of
function pointers in init/fini arrays">;
+defm ptrauth_indirect_gotos :
[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)
https://github.com/ahmedbougacha created
https://github.com/llvm/llvm-project/pull/97647
Enabled in clang using:
-fptrauth-indirect-gotos
and at the IR level using function attribute:
"ptrauth-indirect-gotos"
Signing uses IA and a per-function integer discriminator. The discriminator
isn't ABI-visible, and is currently:
ptrauth_string_discriminator(" blockaddress")
A sufficiently sophisticated frontend could benefit from per-indirectbr
discrimination, which would need additional machinery, such as allowing
"ptrauth" bundles on indirectbr. For our purposes, the simple scheme above is
sufficient.
>From f0d8af86161c6037e9e0d1fe800e5876dd090092 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Tue, 12 Mar 2024 14:40:17 -0700
Subject: [PATCH] [AArch64][PAC] Sign block addresses used in indirectbr.
Enabled in clang using:
-fptrauth-indirect-gotos
and at the IR level using function attribute:
"ptrauth-indirect-gotos"
Signing uses IA and a per-function integer discriminator.
The discriminator isn't ABI-visible, and is currently:
ptrauth_string_discriminator(" blockaddress")
A sufficiently sophisticated frontend could benefit from
per-indirectbr discrimination, which would need additional
machinery, such as allowing "ptrauth" bundles on indirectbr.
For our purposes, the simple scheme above is sufficient.
---
clang/include/clang/Basic/Features.def| 1 +
clang/include/clang/Basic/LangOptions.def | 1 +
.../include/clang/Basic/PointerAuthOptions.h | 3 +
clang/include/clang/Driver/Options.td | 2 +
clang/lib/CodeGen/CodeGenFunction.cpp | 2 +
clang/lib/Driver/ToolChains/Clang.cpp | 3 +
clang/lib/Frontend/CompilerInvocation.cpp | 6 +-
.../CodeGen/ptrauth-function-attributes.c | 5 +
llvm/docs/PointerAuth.md | 24
llvm/include/llvm/CodeGen/AsmPrinter.h| 3 +
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp| 6 +-
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | 35 +-
llvm/lib/Target/AArch64/AArch64FastISel.cpp | 4 +
.../Target/AArch64/AArch64ISelLowering.cpp| 54 -
llvm/lib/Target/AArch64/AArch64ISelLowering.h | 1 +
llvm/lib/Target/AArch64/AArch64InstrInfo.td | 18 +++
llvm/lib/Target/AArch64/AArch64Subtarget.cpp | 11 ++
llvm/lib/Target/AArch64/AArch64Subtarget.h| 9 ++
.../GISel/AArch64InstructionSelector.cpp | 26 +
.../CodeGen/AArch64/ptrauth-indirectbr.ll | 106 ++
20 files changed, 309 insertions(+), 11 deletions(-)
create mode 100644 llvm/test/CodeGen/AArch64/ptrauth-indirectbr.ll
diff --git a/clang/include/clang/Basic/Features.def
b/clang/include/clang/Basic/Features.def
index 53f410d3cb4bd..cf800afe08557 100644
--- a/clang/include/clang/Basic/Features.def
+++ b/clang/include/clang/Basic/Features.def
@@ -108,6 +108,7 @@ FEATURE(ptrauth_calls, LangOpts.PointerAuthCalls)
FEATURE(ptrauth_returns, LangOpts.PointerAuthReturns)
FEATURE(ptrauth_vtable_pointer_address_discrimination,
LangOpts.PointerAuthVTPtrAddressDiscrimination)
FEATURE(ptrauth_vtable_pointer_type_discrimination,
LangOpts.PointerAuthVTPtrTypeDiscrimination)
+FEATURE(ptrauth_indirect_gotos, LangOpts.PointerAuthIndirectGotos)
FEATURE(ptrauth_member_function_pointer_type_discrimination,
LangOpts.PointerAuthCalls)
FEATURE(ptrauth_init_fini, LangOpts.PointerAuthInitFini)
EXTENSION(swiftcc,
diff --git a/clang/include/clang/Basic/LangOptions.def
b/clang/include/clang/Basic/LangOptions.def
index 491759e2fcdbb..bdf77a5b35208 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -165,6 +165,7 @@ LANGOPT(ExperimentalLibrary, 1, 0, "enable unstable and
experimental library fea
LANGOPT(PointerAuthIntrinsics, 1, 0, "pointer authentication intrinsics")
LANGOPT(PointerAuthCalls , 1, 0, "function pointer authentication")
LANGOPT(PointerAuthReturns, 1, 0, "return pointer authentication")
+LANGOPT(PointerAuthIndirectGotos, 1, 0, "indirect gotos pointer
authentication")
LANGOPT(PointerAuthAuthTraps, 1, 0, "pointer authentication failure traps")
LANGOPT(PointerAuthVTPtrAddressDiscrimination, 1, 0, "incorporate address
discrimination in authenticated vtable pointers")
LANGOPT(PointerAuthVTPtrTypeDiscrimination, 1, 0, "incorporate type
discrimination in authenticated vtable pointers")
diff --git a/clang/include/clang/Basic/PointerAuthOptions.h
b/clang/include/clang/Basic/PointerAuthOptions.h
index 197d63642ca6d..2711639dbe299 100644
--- a/clang/include/clang/Basic/PointerAuthOptions.h
+++ b/clang/include/clang/Basic/PointerAuthOptions.h
@@ -154,6 +154,9 @@ class PointerAuthSchema {
};
struct PointerAuthOptions {
+ /// Do indirect goto label addresses need to be authenticated?
+ bool IndirectGotos = false;
+
/// The ABI for C function pointers.
PointerAuthSchema FunctionPointers;
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index
[clang] [clang] Implement pointer authentication for C++ virtual functions, v-tables, and VTTs (PR #94056)
https://github.com/ahmedbougacha closed https://github.com/llvm/llvm-project/pull/94056 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [PAC][clang][Driver] Add signed GOT flag (PR #96160)
ahmedbougacha wrote: >> Do we want a lot of -fptrauth-xxx instead of -fptrauth-something=xxx,yyy,zzz? > > I would lean towards a single flag. Comma-separated flags generally seem less user-friendly (for, e.g., grepping, modifying, reading). To some extent we can mitigate that with the obvious cleverness (e.g., negatives, repetition), at the cost of a lot more driver logic, and even that would only go so far. Is there a compelling argument for them? > However, I do not know how this would affect Apple downstream and what are > preferences there. Yeah, we do already support the long spellings, but we can change these here if we have consensus, and it should be doable to support the long spellings on top of these. https://github.com/llvm/llvm-project/pull/96160 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Implement pointer authentication for C++ virtual functions, v-tables, and VTTs (PR #94056)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/94056 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang] Implement pointer authentication for C++ virtual functions, v-tables, and VTTs (PR #94056)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/94056 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Implement function pointer signing and authenticated function calls (PR #93906)
https://github.com/ahmedbougacha updated
https://github.com/llvm/llvm-project/pull/93906
>From 016baec5833f0fba4280e67ba24caed48e8a1017 Mon Sep 17 00:00:00 2001
From: Akira Hatanaka
Date: Fri, 24 May 2024 20:23:36 -0700
Subject: [PATCH 1/6] [clang] Implement function pointer signing.
Co-Authored-By: John McCall
---
clang/include/clang/Basic/CodeGenOptions.h| 4 +
.../clang/Basic/DiagnosticDriverKinds.td | 3 +
clang/include/clang/Basic/LangOptions.h | 2 +
.../include/clang/Basic/PointerAuthOptions.h | 136 ++
.../clang/Frontend/CompilerInvocation.h | 10 ++
clang/lib/CodeGen/CGBuiltin.cpp | 3 +-
clang/lib/CodeGen/CGCall.cpp | 3 +
clang/lib/CodeGen/CGCall.h| 28 +++-
clang/lib/CodeGen/CGExpr.cpp | 17 +--
clang/lib/CodeGen/CGExprConstant.cpp | 19 ++-
clang/lib/CodeGen/CGPointerAuth.cpp | 51 +++
clang/lib/CodeGen/CGPointerAuthInfo.h | 96 +
clang/lib/CodeGen/CodeGenFunction.cpp | 58
clang/lib/CodeGen/CodeGenFunction.h | 10 ++
clang/lib/CodeGen/CodeGenModule.h | 33 +
clang/lib/Frontend/CompilerInvocation.cpp | 36 +
clang/lib/Headers/ptrauth.h | 34 +
.../CodeGen/ptrauth-function-attributes.c | 13 ++
.../test/CodeGen/ptrauth-function-init-fail.c | 5 +
clang/test/CodeGen/ptrauth-function-init.c| 31
.../CodeGen/ptrauth-function-lvalue-cast.c| 23 +++
clang/test/CodeGen/ptrauth-weak_import.c | 10 ++
clang/test/CodeGenCXX/ptrauth.cpp | 24
23 files changed, 632 insertions(+), 17 deletions(-)
create mode 100644 clang/lib/CodeGen/CGPointerAuthInfo.h
create mode 100644 clang/test/CodeGen/ptrauth-function-attributes.c
create mode 100644 clang/test/CodeGen/ptrauth-function-init-fail.c
create mode 100644 clang/test/CodeGen/ptrauth-function-init.c
create mode 100644 clang/test/CodeGen/ptrauth-function-lvalue-cast.c
create mode 100644 clang/test/CodeGen/ptrauth-weak_import.c
create mode 100644 clang/test/CodeGenCXX/ptrauth.cpp
diff --git a/clang/include/clang/Basic/CodeGenOptions.h
b/clang/include/clang/Basic/CodeGenOptions.h
index 00523a84d3895..f2a707a8ba8d7 100644
--- a/clang/include/clang/Basic/CodeGenOptions.h
+++ b/clang/include/clang/Basic/CodeGenOptions.h
@@ -13,6 +13,7 @@
#ifndef LLVM_CLANG_BASIC_CODEGENOPTIONS_H
#define LLVM_CLANG_BASIC_CODEGENOPTIONS_H
+#include "clang/Basic/PointerAuthOptions.h"
#include "clang/Basic/Sanitizers.h"
#include "clang/Basic/XRayInstr.h"
#include "llvm/ADT/FloatingPointMode.h"
@@ -391,6 +392,9 @@ class CodeGenOptions : public CodeGenOptionsBase {
std::vector Reciprocals;
+ /// Configuration for pointer-signing.
+ PointerAuthOptions PointerAuth;
+
/// The preferred width for auto-vectorization transforms. This is intended
to
/// override default transforms based on the width of the architected vector
/// registers.
diff --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 1ca2cb85565a1..ab002c24eb08c 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -351,6 +351,9 @@ def err_drv_omp_host_ir_file_not_found : Error<
"target regions but cannot be found">;
def err_drv_omp_host_target_not_supported : Error<
"target '%0' is not a supported OpenMP host target">;
+def err_drv_ptrauth_not_supported : Error<
+ "target '%0' does not support native pointer authentication">;
+
def err_drv_expecting_fopenmp_with_fopenmp_targets : Error<
"'-fopenmp-targets' must be used in conjunction with a '-fopenmp' option "
"compatible with offloading; e.g., '-fopenmp=libomp' or
'-fopenmp=libiomp5'">;
diff --git a/clang/include/clang/Basic/LangOptions.h
b/clang/include/clang/Basic/LangOptions.h
index 75e88afbd9705..5216822e45b1b 100644
--- a/clang/include/clang/Basic/LangOptions.h
+++ b/clang/include/clang/Basic/LangOptions.h
@@ -346,6 +346,8 @@ class LangOptionsBase {
BKey
};
+ using PointerAuthenticationMode = ::clang::PointerAuthenticationMode;
+
enum class ThreadModelKind {
/// POSIX Threads.
POSIX,
diff --git a/clang/include/clang/Basic/PointerAuthOptions.h
b/clang/include/clang/Basic/PointerAuthOptions.h
index e5cdcc31ebfb7..32b179e3f9460 100644
--- a/clang/include/clang/Basic/PointerAuthOptions.h
+++ b/clang/include/clang/Basic/PointerAuthOptions.h
@@ -14,10 +14,146 @@
#ifndef LLVM_CLANG_BASIC_POINTERAUTHOPTIONS_H
#define LLVM_CLANG_BASIC_POINTERAUTHOPTIONS_H
+#include "clang/Basic/LLVM.h"
+#include "clang/Basic/LangOptions.h"
+#include "llvm/Support/ErrorHandling.h"
+#include "llvm/Target/TargetOptions.h"
+#include
+#include
+#include
+#include
+
namespace clang {
constexpr unsigned PointerAuthKeyNone = -1;
+class PointerAuthSchema {
+public:
+ enum class Kind : unsigned {
[clang] [clang] Define ptrauth_sign_constant builtin. (PR #93904)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/93904 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang] Implement function pointer signing and authenticated function calls (PR #93906)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/93906 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Define ptrauth_sign_constant builtin. (PR #93904)
https://github.com/ahmedbougacha closed https://github.com/llvm/llvm-project/pull/93904 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Define ptrauth_sign_constant builtin. (PR #93904)
https://github.com/ahmedbougacha updated
https://github.com/llvm/llvm-project/pull/93904
>From 2767407e2970d6fb8b0e651d80162d9481129258 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Thu, 30 May 2024 17:33:04 -0700
Subject: [PATCH 1/6] [clang] Define ptrauth_sign_constant builtin.
This is constant-expression equivalent to __builtin_ptrauth_sign,
allowing its usage in global initializers, but requiring constant
pointers and discriminators.
Co-Authored-By: John McCall
---
clang/include/clang/Basic/Builtins.td | 6 +
.../clang/Basic/DiagnosticSemaKinds.td| 7 +
clang/include/clang/CodeGen/CodeGenABITypes.h | 6 +
clang/lib/AST/ExprConstant.cpp| 1 +
clang/lib/CodeGen/CGBuiltin.cpp | 3 +
clang/lib/CodeGen/CGExprConstant.cpp | 62 +
clang/lib/CodeGen/CGPointerAuth.cpp | 77 +++
clang/lib/CodeGen/CMakeLists.txt | 1 +
clang/lib/CodeGen/CodeGenModule.h | 5 +
clang/lib/Headers/ptrauth.h | 25
clang/lib/Sema/SemaChecking.cpp | 128 --
.../CodeGen/ptrauth-intrinsic-sign-constant.c | 20 +++
clang/test/Sema/ptrauth-intrinsics-macro.c| 4 +
clang/test/Sema/ptrauth.c | 28
14 files changed, 359 insertions(+), 14 deletions(-)
create mode 100644 clang/lib/CodeGen/CGPointerAuth.cpp
create mode 100644 clang/test/CodeGen/ptrauth-intrinsic-sign-constant.c
diff --git a/clang/include/clang/Basic/Builtins.td
b/clang/include/clang/Basic/Builtins.td
index e07ddf3b9b70b..9342b6bc75fc8 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -4393,6 +4393,12 @@ def PtrauthSignUnauthenticated : Builtin {
let Prototype = "void*(void*,int,void*)";
}
+def PtrauthSignConstant : Builtin {
+ let Spellings = ["__builtin_ptrauth_sign_constant"];
+ let Attributes = [CustomTypeChecking, NoThrow, Const, Constexpr];
+ let Prototype = "void*(void*,int,void*)";
+}
+
def PtrauthSignGenericData : Builtin {
let Spellings = ["__builtin_ptrauth_sign_generic_data"];
let Attributes = [CustomTypeChecking, NoThrow, Const];
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 043d73d223376..9bf55acbac011 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -924,6 +924,13 @@ def err_ptrauth_value_bad_type :
Error<"%select{signed value|extra discriminator|blended pointer|blended "
"integer}0 must have %select{pointer|integer|pointer or integer}1 "
"type; type here is %2">;
+def err_ptrauth_bad_constant_pointer :
+ Error<"argument to ptrauth_sign_constant must refer to a global variable "
+"or function">;
+def err_ptrauth_bad_constant_discriminator :
+ Error<"discriminator argument to ptrauth_sign_constant must be a constant "
+"integer, the address of the global variable where the result "
+"will be stored, or a blend of the two">;
def warn_ptrauth_sign_null_pointer :
Warning<"signing a null pointer will yield a non-null pointer">,
InGroup;
diff --git a/clang/include/clang/CodeGen/CodeGenABITypes.h
b/clang/include/clang/CodeGen/CodeGenABITypes.h
index fda0855dc8683..8c62d8597ecbe 100644
--- a/clang/include/clang/CodeGen/CodeGenABITypes.h
+++ b/clang/include/clang/CodeGen/CodeGenABITypes.h
@@ -104,6 +104,12 @@ llvm::Type *convertTypeForMemory(CodeGenModule ,
QualType T);
unsigned getLLVMFieldNumber(CodeGenModule ,
const RecordDecl *RD, const FieldDecl *FD);
+/// Return a signed constant pointer.
+llvm::Constant *getConstantSignedPointer(CodeGenModule ,
+ llvm::Constant *pointer,
+ unsigned key,
+ llvm::Constant *storageAddress,
+ llvm::Constant *otherDiscriminator);
/// Given the language and code-generation options that Clang was configured
/// with, set the default LLVM IR attributes for a function definition.
/// The attributes set here are mostly global target-configuration and
diff --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index 0576516608ddd..fe4b9a569ab87 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -2042,6 +2042,7 @@ static bool IsNoOpCall(const CallExpr *E) {
unsigned Builtin = E->getBuiltinCallee();
return (Builtin == Builtin::BI__builtin___CFStringMakeConstantString ||
Builtin == Builtin::BI__builtin___NSStringMakeConstantString ||
+ Builtin == Builtin::BI__builtin_ptrauth_sign_constant ||
Builtin == Builtin::BI__builtin_function_start);
}
diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 931726a78dae9..2516ed4508242 100644
---
[clang] [clang] Define ptrauth_sign_constant builtin. (PR #93904)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/93904 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Define ptrauth_string_discriminator builtin. (PR #93903)
https://github.com/ahmedbougacha closed https://github.com/llvm/llvm-project/pull/93903 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Define ptrauth_string_discriminator builtin. (PR #93903)
@@ -328,6 +328,21 @@ be done in a single instruction with an immediate integer. ``pointer`` must have pointer type, and ``integer`` must have integer type. The result has type ``ptrauth_extra_data_t``. +``ptrauth_string_discriminator`` + + +.. code-block:: c + + ptrauth_string_discriminator(string) + +Produce a discriminator value for the given string. ``string`` must be +a string literal of ``char`` character type. The result has type +``ptrauth_extra_data_t``. + +The result is always a constant expression. The result value is never zero and +always within range for both the ``__ptrauth`` qualifier and ahmedbougacha wrote: That's with `ptrauth_blend_discriminator` https://github.com/llvm/llvm-project/pull/93903 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Define ptrauth_string_discriminator builtin. (PR #93903)
https://github.com/ahmedbougacha updated
https://github.com/llvm/llvm-project/pull/93903
>From 607592e7071a604fc63252cb3686545ed1f1b0b8 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Thu, 30 May 2024 17:22:29 -0700
Subject: [PATCH 1/6] [clang] Define ptrauth_string_discriminator builtin.
This exposes the ABI-stable hash function that allows computing a 16-bit
discriminator from a constant string.
This allows manually matching the implicit string discriminators
computed in the ABI (e.g., from mangled names for vtable pointer/entry
signing), as well as enabling the use of interesting discriminators when
manually annotating specific pointers with the __ptrauth qualifier.
Co-Authored-By: John McCall
---
clang/include/clang/Basic/Builtins.td | 6 ++
.../clang/Basic/DiagnosticSemaKinds.td| 2 ++
clang/lib/AST/ExprConstant.cpp| 7 +++
clang/lib/Headers/ptrauth.h | 17
clang/lib/Sema/SemaChecking.cpp | 20 +++
clang/test/CodeGen/ptrauth-intrinsics.c | 13
clang/test/Sema/ptrauth-intrinsics-macro.c| 5 +
7 files changed, 70 insertions(+)
diff --git a/clang/include/clang/Basic/Builtins.td
b/clang/include/clang/Basic/Builtins.td
index 7bef5fd7ad40f..e07ddf3b9b70b 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -4411,6 +4411,12 @@ def PtrauthAuth : Builtin {
let Prototype = "void*(void*,int,void*)";
}
+def PtrauthStringDiscriminator : Builtin {
+ let Spellings = ["__builtin_ptrauth_string_discriminator"];
+ let Attributes = [NoThrow, Const, Constexpr];
+ let Prototype = "size_t(char const*)";
+}
+
// OpenCL v2.0 s6.13.16, s9.17.3.5 - Pipe functions.
// We need the generic prototype, since the packet type could be anything.
def ReadPipe : OCLPipeLangBuiltin {
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 14736784cff5f..0900dad3c18cd 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -930,6 +930,8 @@ def warn_ptrauth_sign_null_pointer :
def warn_ptrauth_auth_null_pointer :
Warning<"authenticating a null pointer will almost certainly trap">,
InGroup;
+def err_ptrauth_string_not_literal : Error<
+ "argument must be a string literal%select{| of char type}0">;
/// main()
// static main() is not an error in C, just in C++.
diff --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index 9ac53438de8e4..c9467c5ea1847 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -58,6 +58,7 @@
#include "llvm/ADT/StringExtras.h"
#include "llvm/Support/Debug.h"
#include "llvm/Support/SaveAndRestore.h"
+#include "llvm/Support/SipHash.h"
#include "llvm/Support/TimeProfiler.h"
#include "llvm/Support/raw_ostream.h"
#include
@@ -12590,6 +12591,12 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
case Builtin::BI__builtin_expect_with_probability:
return Visit(E->getArg(0));
+ case Builtin::BI__builtin_ptrauth_string_discriminator: {
+auto literal = cast(E->getArg(0)->IgnoreParenImpCasts());
+auto result = getPointerAuthStableSipHash16(literal->getString());
+return Success(result, E);
+ }
+
case Builtin::BI__builtin_ffs:
case Builtin::BI__builtin_ffsl:
case Builtin::BI__builtin_ffsll: {
diff --git a/clang/lib/Headers/ptrauth.h b/clang/lib/Headers/ptrauth.h
index a9d182aa24470..cce639dc8170c 100644
--- a/clang/lib/Headers/ptrauth.h
+++ b/clang/lib/Headers/ptrauth.h
@@ -125,6 +125,17 @@ typedef __UINTPTR_TYPE__ ptrauth_generic_signature_t;
#define ptrauth_auth_data(__value, __old_key, __old_data)
\
__builtin_ptrauth_auth(__value, __old_key, __old_data)
+/* Compute a constant discriminator from the given string.
+
+ The result can be used as the second argument to
+ ptrauth_blend_discriminator or the third argument to the
+ __ptrauth qualifier. It has type size_t.
+
+ The argument must be a string literal.
+ A call to this function is an integer constant expression. */
+#define ptrauth_string_discriminator(__string)
\
+ __builtin_ptrauth_string_discriminator(__string)
+
/* Compute a signature for the given pair of pointer-sized values.
The order of the arguments is significant.
@@ -186,6 +197,12 @@ typedef __UINTPTR_TYPE__ ptrauth_generic_signature_t;
__value;
\
})
+#define ptrauth_string_discriminator(__string)
\
+ ({
\
+(void)__string;
\
+((ptrauth_extra_data_t)0);
\
+ })
+
#define
[clang] [llvm] [clang] Define ptrauth_string_discriminator builtin. (PR #93903)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/93903 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [llvm][AArch64] Support -mcpu=apple-m4 (PR #95478)
https://github.com/ahmedbougacha approved this pull request. https://github.com/llvm/llvm-project/pull/95478 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [llvm][AArch64] Rearrange Apple CPUs by generation, not product class. NFC (PR #95579)
@@ -983,50 +1007,58 @@ def : ProcessorModel<"thunderx3t110", ThunderX3T110Model, def : ProcessorModel<"tsv110", TSV110Model, ProcessorFeatures.TSV110, [TuneTSV110]>; +// iPhone, iPad, Mac and Watch CPUs ahmedbougacha wrote: Certainly minor, but maybe just "Apple CPUs" https://github.com/llvm/llvm-project/pull/95579 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [llvm][AArch64] Rearrange Apple CPUs by generation, not product class. NFC (PR #95579)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/95579 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [llvm][AArch64] Rearrange Apple CPUs by generation, not product class. NFC (PR #95579)
https://github.com/ahmedbougacha approved this pull request. https://github.com/llvm/llvm-project/pull/95579 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] set AppleA14 architecture version to v8.4-a (PR #92600)
@@ -718,12 +718,16 @@ def ProcessorFeatures {
list AppleA13 = [HasV8_4aOps, FeatureCrypto,
FeatureFPARMv8,
FeatureNEON, FeaturePerfMon,
FeatureFullFP16,
FeatureFP16FML, FeatureSHA3];
+ // Apple A14 and M1 chips are based on Armv8.5-a but without BTI. Since there
ahmedbougacha wrote:
No, because this isn't documentation for these cores, nor should it be. There
is no documentation beyond the optimization guide mentioned above publicly
available today.
https://github.com/llvm/llvm-project/pull/92600
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Fix feature flags dependecies (PR #90612)
ahmedbougacha wrote: > The overall idea is that system registers ought be available everywhere > without the need to explicitly enable them with a command line option. Interesting, that's kind of what I'm getting at: longer term, are you saying you folks are considering removing the feature predicates on all system registers (i.e., `AArch64SystemOperands.td`), or are you thinking of treating FPMR specifically as a first-class register, the way we do NZCV or FPCR? I'd be curious to see how the latter goes, since it seems likely to be almost required for any kind of meaningful FP8 codegen... As for sysregs in general, I think we'd still want the ability to have predicates, in part because some of them can have conflicting encodings, in part to catch obvious mistakes when writing asm; the specific subtarget features would matter. But yeah, on most of them, mainly the architected ones, it's probably fine to do away with feature requirements. https://github.com/llvm/llvm-project/pull/90612 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] set AppleA14 architecture version to v8.4-a (PR #92600)
ahmedbougacha wrote: > > Correct, apple-m1 does not have BTI, but BTI is required for v8.5. My > > mistake. > > Not sure if you are involved in writing the optimization guide itself at > Apple, but the way the chip is described as having 8.5 minus BTI is a bit > confusing since that would technically make the chip not v8.5 @jroelofs Sure, it makes the chip "v8.5 (excluding FEAT_BTI)", which is what's written in the guide ;) The guide is intended as a human-readable guide for high-performance software writers, not as much as the almost-only-machine-readable specifications we're used to reading. The alternative would have been "v8.4a + all these features from v8.5" which is worse. https://github.com/llvm/llvm-project/pull/92600 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] set AppleA14 architecture version to v8.4-a (PR #92600)
@@ -718,12 +718,16 @@ def ProcessorFeatures {
list AppleA13 = [HasV8_4aOps, FeatureCrypto,
FeatureFPARMv8,
FeatureNEON, FeaturePerfMon,
FeatureFullFP16,
FeatureFP16FML, FeatureSHA3];
+ // Apple A14 and M1 chips are based on Armv8.5-a but without BTI. Since there
ahmedbougacha wrote:
Well, on the flipside, having one specific quirk called out somewhere and no
other quirk called out elsewhere would only instill misplaced confidence in
anyone who would want to update these cpu definitions.
https://github.com/llvm/llvm-project/pull/92600
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Support] Add SipHash-based 16/64-bit ptrauth stable hash. (PR #93902)
https://github.com/ahmedbougacha updated
https://github.com/llvm/llvm-project/pull/93902
>From fc8f76b404b25951dc10ecaaa760b4b4c3d4f858 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Thu, 30 May 2024 17:07:04 -0700
Subject: [PATCH 1/2] [clang] Add arm64e ABI-defined key assignments to
ptrauth.h.
These are currently gated by __APPLE__; we can figure out a way to
define these on ELF targets as well, and maybe have them be defined
by clang itself, depending on ABI modes.
---
clang/lib/Headers/ptrauth.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/clang/lib/Headers/ptrauth.h b/clang/lib/Headers/ptrauth.h
index 56c3c3636c9bc..036665d75a91b 100644
--- a/clang/lib/Headers/ptrauth.h
+++ b/clang/lib/Headers/ptrauth.h
@@ -15,6 +15,29 @@ typedef enum {
ptrauth_key_asib = 1,
ptrauth_key_asda = 2,
ptrauth_key_asdb = 3,
+
+#ifdef __APPLE__
+ /* A process-independent key which can be used to sign code pointers.
+ Signing and authenticating with this key is a no-op in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_independent_code = ptrauth_key_asia,
+
+ /* A process-specific key which can be used to sign code pointers.
+ Signing and authenticating with this key is enforced even in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_dependent_code = ptrauth_key_asib,
+
+ /* A process-independent key which can be used to sign data pointers.
+ Signing and authenticating with this key is a no-op in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_independent_data = ptrauth_key_asda,
+
+ /* A process-specific key which can be used to sign data pointers.
+ Signing and authenticating with this key is a no-op in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_dependent_data = ptrauth_key_asdb,
+#endif /* __APPLE__ */
+
} ptrauth_key;
/* An integer type of the appropriate size for a discriminator argument. */
>From 42cb73fecf1033aefbe824149f3d8a5352bb2103 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Thu, 30 May 2024 17:05:31 -0700
Subject: [PATCH 2/2] [Support] Add SipHash-based 16/64-bit ptrauth stable
hash.
Based on the SipHash reference implementation:
https://github.com/veorq/SipHash
which has very graciously been licensed under our llvm license
(Apache-2.0 WITH LLVM-exception) by Jean-Philippe Aumasson.
This lightly modifies it to fit into libSupport, and wraps it for the
two main interfaces we're interested in (16/64-bit).
This intentionally doesn't expose a raw interface beyond that to
encourage others to carefully consider their use.
The exact algorithm is the little-endian interpretation of the
non-doubled (i.e. 64-bit) result of applying a SipHash-2-4 using
a specific key value which can be found in the source.
By "stable" we mean that the result of this hash algorithm will the same
across different compiler versions and target platforms.
The 16-bit variant is used extensively for the AArch64 ptrauth ABI,
because AArch64 can efficiently load a 16-bit immediate into the high
bits of a register without disturbing the remainder of the value, which
serves as a nice blend operation.
16 bits is also sufficiently compact to not inflate a loader relocation.
We disallow zero to guarantee a different discriminator from the places
in the ABI that use a constant zero.
Co-Authored-By: John McCall
---
llvm/include/llvm/Support/SipHash.h| 47 +++
llvm/lib/Support/CMakeLists.txt| 1 +
llvm/lib/Support/SipHash.cpp | 174 +
llvm/unittests/Support/CMakeLists.txt | 1 +
llvm/unittests/Support/SipHashTest.cpp | 43 ++
5 files changed, 266 insertions(+)
create mode 100644 llvm/include/llvm/Support/SipHash.h
create mode 100644 llvm/lib/Support/SipHash.cpp
create mode 100644 llvm/unittests/Support/SipHashTest.cpp
diff --git a/llvm/include/llvm/Support/SipHash.h
b/llvm/include/llvm/Support/SipHash.h
new file mode 100644
index 0..fcc29c00da185
--- /dev/null
+++ b/llvm/include/llvm/Support/SipHash.h
@@ -0,0 +1,47 @@
+//===--- SipHash.h - An ABI-stable string SipHash ---*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// A family of ABI-stable string hash algorithms based on SipHash, currently
+// used to compute ptrauth discriminators.
+//
+//===--===//
+
+#ifndef LLVM_SUPPORT_SIPHASH_H
+#define LLVM_SUPPORT_SIPHASH_H
+
+#include
+
+namespace llvm {
+class StringRef;
+
+/// Compute a stable 64-bit hash of the given string.
+///
+/// The exact algorithm is the little-endian interpretation of
[clang] [llvm] [Support] Add SipHash-based 16/64-bit ptrauth stable hash. (PR #93902)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/93902 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Add arm64e ABI-defined key assignments to ptrauth.h. (PR #93901)
https://github.com/ahmedbougacha closed https://github.com/llvm/llvm-project/pull/93901 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Add arm64e ABI-defined key assignments to ptrauth.h. (PR #93901)
@@ -15,6 +15,29 @@ typedef enum {
ptrauth_key_asib = 1,
ptrauth_key_asda = 2,
ptrauth_key_asdb = 3,
+
+#ifdef __APPLE__
ahmedbougacha wrote:
Great, let's do that; I also removed the comments that talk about enablement
policy, that seems like a separate problem if this is to be generic
https://github.com/llvm/llvm-project/pull/93901
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Add arm64e ABI-defined key assignments to ptrauth.h. (PR #93901)
https://github.com/ahmedbougacha updated
https://github.com/llvm/llvm-project/pull/93901
>From fc8f76b404b25951dc10ecaaa760b4b4c3d4f858 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Thu, 30 May 2024 17:07:04 -0700
Subject: [PATCH 1/2] [clang] Add arm64e ABI-defined key assignments to
ptrauth.h.
These are currently gated by __APPLE__; we can figure out a way to
define these on ELF targets as well, and maybe have them be defined
by clang itself, depending on ABI modes.
---
clang/lib/Headers/ptrauth.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/clang/lib/Headers/ptrauth.h b/clang/lib/Headers/ptrauth.h
index 56c3c3636c9bc..036665d75a91b 100644
--- a/clang/lib/Headers/ptrauth.h
+++ b/clang/lib/Headers/ptrauth.h
@@ -15,6 +15,29 @@ typedef enum {
ptrauth_key_asib = 1,
ptrauth_key_asda = 2,
ptrauth_key_asdb = 3,
+
+#ifdef __APPLE__
+ /* A process-independent key which can be used to sign code pointers.
+ Signing and authenticating with this key is a no-op in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_independent_code = ptrauth_key_asia,
+
+ /* A process-specific key which can be used to sign code pointers.
+ Signing and authenticating with this key is enforced even in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_dependent_code = ptrauth_key_asib,
+
+ /* A process-independent key which can be used to sign data pointers.
+ Signing and authenticating with this key is a no-op in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_independent_data = ptrauth_key_asda,
+
+ /* A process-specific key which can be used to sign data pointers.
+ Signing and authenticating with this key is a no-op in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_dependent_data = ptrauth_key_asdb,
+#endif /* __APPLE__ */
+
} ptrauth_key;
/* An integer type of the appropriate size for a discriminator argument. */
>From 235f85f988c32c0efd3861ed15810441dcfeb07e Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Fri, 31 May 2024 12:52:41 -0700
Subject: [PATCH 2/2] Don't gate by __APPLE__, remove darwin-specific comments.
---
clang/lib/Headers/ptrauth.h | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/clang/lib/Headers/ptrauth.h b/clang/lib/Headers/ptrauth.h
index 036665d75a91b..a9d182aa24470 100644
--- a/clang/lib/Headers/ptrauth.h
+++ b/clang/lib/Headers/ptrauth.h
@@ -16,27 +16,17 @@ typedef enum {
ptrauth_key_asda = 2,
ptrauth_key_asdb = 3,
-#ifdef __APPLE__
- /* A process-independent key which can be used to sign code pointers.
- Signing and authenticating with this key is a no-op in processes
- which disable ABI pointer authentication. */
+ /* A process-independent key which can be used to sign code pointers. */
ptrauth_key_process_independent_code = ptrauth_key_asia,
- /* A process-specific key which can be used to sign code pointers.
- Signing and authenticating with this key is enforced even in processes
- which disable ABI pointer authentication. */
+ /* A process-specific key which can be used to sign code pointers. */
ptrauth_key_process_dependent_code = ptrauth_key_asib,
- /* A process-independent key which can be used to sign data pointers.
- Signing and authenticating with this key is a no-op in processes
- which disable ABI pointer authentication. */
+ /* A process-independent key which can be used to sign data pointers. */
ptrauth_key_process_independent_data = ptrauth_key_asda,
- /* A process-specific key which can be used to sign data pointers.
- Signing and authenticating with this key is a no-op in processes
- which disable ABI pointer authentication. */
+ /* A process-specific key which can be used to sign data pointers. */
ptrauth_key_process_dependent_data = ptrauth_key_asdb,
-#endif /* __APPLE__ */
} ptrauth_key;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Add arm64e ABI-defined key assignments to ptrauth.h. (PR #93901)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/93901 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Add arm64e ABI-defined key assignments to ptrauth.h. (PR #93901)
https://github.com/ahmedbougacha created
https://github.com/llvm/llvm-project/pull/93901
These are currently gated by __APPLE__; we can figure out a way to define these
on ELF targets as well, and maybe have them be defined by clang itself,
depending on ABI modes.
>From fc8f76b404b25951dc10ecaaa760b4b4c3d4f858 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Thu, 30 May 2024 17:07:04 -0700
Subject: [PATCH] [clang] Add arm64e ABI-defined key assignments to ptrauth.h.
These are currently gated by __APPLE__; we can figure out a way to
define these on ELF targets as well, and maybe have them be defined
by clang itself, depending on ABI modes.
---
clang/lib/Headers/ptrauth.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/clang/lib/Headers/ptrauth.h b/clang/lib/Headers/ptrauth.h
index 56c3c3636c9bc..036665d75a91b 100644
--- a/clang/lib/Headers/ptrauth.h
+++ b/clang/lib/Headers/ptrauth.h
@@ -15,6 +15,29 @@ typedef enum {
ptrauth_key_asib = 1,
ptrauth_key_asda = 2,
ptrauth_key_asdb = 3,
+
+#ifdef __APPLE__
+ /* A process-independent key which can be used to sign code pointers.
+ Signing and authenticating with this key is a no-op in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_independent_code = ptrauth_key_asia,
+
+ /* A process-specific key which can be used to sign code pointers.
+ Signing and authenticating with this key is enforced even in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_dependent_code = ptrauth_key_asib,
+
+ /* A process-independent key which can be used to sign data pointers.
+ Signing and authenticating with this key is a no-op in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_independent_data = ptrauth_key_asda,
+
+ /* A process-specific key which can be used to sign data pointers.
+ Signing and authenticating with this key is a no-op in processes
+ which disable ABI pointer authentication. */
+ ptrauth_key_process_dependent_data = ptrauth_key_asdb,
+#endif /* __APPLE__ */
+
} ptrauth_key;
/* An integer type of the appropriate size for a discriminator argument. */
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Fix feature flags dependecies (PR #90612)
ahmedbougacha wrote: > This patch removes FEAT_FPMR from list of available of architecture features, > instead enabling FMPR register by default. Can you expand a little bit on the reasoning? It doesn't seem all that problematic but is still eyebrow-raising. https://github.com/llvm/llvm-project/pull/90612 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] set AppleA14 architecture version to v8.4-a (PR #92600)
@@ -718,12 +718,16 @@ def ProcessorFeatures {
list AppleA13 = [HasV8_4aOps, FeatureCrypto,
FeatureFPARMv8,
FeatureNEON, FeaturePerfMon,
FeatureFullFP16,
FeatureFP16FML, FeatureSHA3];
+ // Apple A14 and M1 chips are based on Armv8.5-a but without BTI. Since there
ahmedbougacha wrote:
I don't think we need to emphasize this here or in `aarch64-target-features.c`;
it's just v8.4a with some bits from .5, and there are other instances of that.
This wasn't always explained clearly in the ARM ARM extension list, but the
more recent issues make this pattern explicit (e.g., looking at DDI 0487K.a:
A2.1.1, or the start of A2.2.5)
https://github.com/llvm/llvm-project/pull/92600
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][CodeGen] Remove unused LValue::getAddress CGF arg. (PR #92465)
https://github.com/ahmedbougacha closed https://github.com/llvm/llvm-project/pull/92465 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CodeGen][AArch64][FMV] PAC the stub_helper's frame on arm64e (PR #84704)
@@ -2085,6 +2099,37 @@ void
AArch64AsmPrinter::emitMachOIFuncStubHelperBody(Module ,
.addImm(2),
*STI);
+ if (TM.getTargetTriple().isArm64e()) {
+// autibsp
ahmedbougacha wrote:
There is not, but send me your patch and I'll tack it onto the relevant commit
(and split the tail-call check emission into a helper)
https://github.com/llvm/llvm-project/pull/84704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha closed https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha updated https://github.com/llvm/llvm-project/pull/65996 >From 1492d6362a1a4f6d65fb7001bdefb5250f30754e Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Wed, 16 Aug 2023 09:17:12 -0700 Subject: [PATCH] [AArch64][PAC] Support and document ptrauth builtins and -fptrauth-intrinsics. This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, in addition to these builtins. Co-Authored-By: Akira Hatanaka Co-Authored-By: John McCall --- clang/docs/LanguageExtensions.rst | 5 + clang/docs/PointerAuthentication.rst | 485 ++ clang/include/clang/Basic/Builtins.td | 37 ++ clang/include/clang/Basic/DiagnosticGroups.td | 1 + .../clang/Basic/DiagnosticSemaKinds.td| 16 + clang/include/clang/Basic/Features.def| 1 + clang/include/clang/Basic/LangOptions.def | 2 + clang/include/clang/Basic/TargetInfo.h| 6 + clang/include/clang/Driver/Options.td | 8 + clang/include/clang/Sema/Sema.h | 2 + clang/lib/Basic/TargetInfo.cpp| 4 + clang/lib/Basic/Targets/AArch64.cpp | 6 + clang/lib/Basic/Targets/AArch64.h | 2 + clang/lib/CodeGen/CGBuiltin.cpp | 67 +++ clang/lib/Driver/ToolChains/Clang.cpp | 4 + clang/lib/Frontend/CompilerInvocation.cpp | 14 + clang/lib/Headers/CMakeLists.txt | 1 + clang/lib/Headers/module.modulemap| 5 + clang/lib/Headers/ptrauth.h | 185 +++ clang/lib/Sema/SemaChecking.cpp | 197 +++ clang/test/CodeGen/ptrauth-intrinsics.c | 73 +++ clang/test/Preprocessor/ptrauth_feature.c | 10 + clang/test/Sema/ptrauth-intrinsics-macro.c| 34 ++ clang/test/Sema/ptrauth.c | 126 + llvm/docs/PointerAuth.md | 3 + 25 files changed, 1294 insertions(+) create mode 100644 clang/docs/PointerAuthentication.rst create mode 100644 clang/lib/Headers/ptrauth.h create mode 100644 clang/test/CodeGen/ptrauth-intrinsics.c create mode 100644 clang/test/Preprocessor/ptrauth_feature.c create mode 100644 clang/test/Sema/ptrauth-intrinsics-macro.c create mode 100644 clang/test/Sema/ptrauth.c diff --git a/clang/docs/LanguageExtensions.rst b/clang/docs/LanguageExtensions.rst index 225736009d4869..13d7261d83d7f1 100644 --- a/clang/docs/LanguageExtensions.rst +++ b/clang/docs/LanguageExtensions.rst @@ -13,6 +13,7 @@ Clang Language Extensions BlockLanguageSpec Block-ABI-Apple AutomaticReferenceCounting + PointerAuthentication MatrixTypes Introduction @@ -4318,6 +4319,10 @@ reordering of memory accesses and side effect instructions. Other instructions like simple arithmetic may be reordered around the intrinsic. If you expect to have no reordering at all, use inline assembly instead. +Pointer Authentication +^^ +See :doc:`PointerAuthentication`. + X86/X86-64 Language Extensions -- diff --git a/clang/docs/PointerAuthentication.rst b/clang/docs/PointerAuthentication.rst new file mode 100644 index 00..19b3384293aede --- /dev/null +++ b/clang/docs/PointerAuthentication.rst @@ -0,0 +1,485 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic +protection against exploiting a broad class of memory bugs to take control of +program execution. When adopted consistently in a language ABI, it provides +a form of relatively fine-grained control flow integrity (CFI) check that +resists both return-oriented programming (ROP) and jump-oriented programming +(JOP) attacks. + +While pointer authentication can be implemented purely in software, direct +hardware support (e.g. as provided by Armv8.3 PAuth) can dramatically improve +performance and code size. Similarly, while pointer authentication +can be implemented on any architecture, taking advantage of the (typically) +excess addressing range of a target with 64-bit pointers minimizes the impact +on memory performance and can allow interoperation with existing code (by +disabling pointer authentication dynamically). This document will generally +attempt to present the pointer authentication feature independent of any +hardware implementation or ABI. Considerations that are +implementation-specific are clearly identified throughout. + +Note that
[clang] [llvm] [CodeGen][AArch64][FMV] PAC the stub_helper's frame on arm64e (PR #84704)
@@ -2085,6 +2099,37 @@ void
AArch64AsmPrinter::emitMachOIFuncStubHelperBody(Module ,
.addImm(2),
*STI);
+ if (TM.getTargetTriple().isArm64e()) {
+// autibsp
ahmedbougacha wrote:
Leave the tail-call checking for the general tail-call checking patches, no?
https://github.com/llvm/llvm-project/pull/84704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
ahmedbougacha wrote: Updated, tried to address all the comments; let me know if I missed something! https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,265 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3 PAuth) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **PAuth** (sometimes referred to as **PAC**, for Pointer Authentication Codes) is an AArch64 architecture extension that provides hardware support for pointer authentication. + +- **ARMv8.3** is an AArch64 architecture revision that makes PAuth mandatory. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI (not yet fully stable) for implementing pointer authentication using PAuth on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It will eventually present a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,265 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3 PAuth) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **PAuth** (sometimes referred to as **PAC**, for Pointer Authentication Codes) is an AArch64 architecture extension that provides hardware support for pointer authentication. + +- **ARMv8.3** is an AArch64 architecture revision that makes PAuth mandatory. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI (not yet fully stable) for implementing pointer authentication using PAuth on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It will eventually present a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,265 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3 PAuth) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **PAuth** (sometimes referred to as **PAC**, for Pointer Authentication Codes) is an AArch64 architecture extension that provides hardware support for pointer authentication. + +- **ARMv8.3** is an AArch64 architecture revision that makes PAuth mandatory. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI (not yet fully stable) for implementing pointer authentication using PAuth on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It will eventually present a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. ahmedbougacha wrote: Yeah, I added "concrete" when describing the key value, as opposed to "abstract" key names/IDs such as "ASIA". https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha updated https://github.com/llvm/llvm-project/pull/65996 >From c5cde09a5ea4a4cfcf3287f7462c38335493c02d Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Wed, 16 Aug 2023 09:17:12 -0700 Subject: [PATCH] [AArch64][PAC] Support and document ptrauth builtins and -fptrauth-intrinsics. This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, in addition to these builtins. Co-Authored-By: Akira Hatanaka Co-Authored-By: John McCall --- clang/docs/LanguageExtensions.rst | 5 + clang/docs/PointerAuthentication.rst | 485 ++ clang/include/clang/Basic/Builtins.td | 37 ++ clang/include/clang/Basic/DiagnosticGroups.td | 1 + .../clang/Basic/DiagnosticSemaKinds.td| 16 + clang/include/clang/Basic/Features.def| 1 + clang/include/clang/Basic/LangOptions.def | 2 + clang/include/clang/Basic/TargetInfo.h| 6 + clang/include/clang/Driver/Options.td | 8 + clang/include/clang/Sema/Sema.h | 2 + clang/lib/Basic/TargetInfo.cpp| 4 + clang/lib/Basic/Targets/AArch64.cpp | 6 + clang/lib/Basic/Targets/AArch64.h | 2 + clang/lib/CodeGen/CGBuiltin.cpp | 67 +++ clang/lib/Driver/ToolChains/Clang.cpp | 4 + clang/lib/Frontend/CompilerInvocation.cpp | 14 + clang/lib/Headers/CMakeLists.txt | 1 + clang/lib/Headers/module.modulemap| 5 + clang/lib/Headers/ptrauth.h | 185 +++ clang/lib/Sema/SemaChecking.cpp | 197 +++ clang/test/CodeGen/ptrauth-intrinsics.c | 73 +++ clang/test/Preprocessor/ptrauth_feature.c | 10 + clang/test/Sema/ptrauth-intrinsics-macro.c| 34 ++ clang/test/Sema/ptrauth.c | 126 + llvm/docs/PointerAuth.md | 3 + 25 files changed, 1294 insertions(+) create mode 100644 clang/docs/PointerAuthentication.rst create mode 100644 clang/lib/Headers/ptrauth.h create mode 100644 clang/test/CodeGen/ptrauth-intrinsics.c create mode 100644 clang/test/Preprocessor/ptrauth_feature.c create mode 100644 clang/test/Sema/ptrauth-intrinsics-macro.c create mode 100644 clang/test/Sema/ptrauth.c diff --git a/clang/docs/LanguageExtensions.rst b/clang/docs/LanguageExtensions.rst index 711baf45f449a05..c818a1d805f51e1 100644 --- a/clang/docs/LanguageExtensions.rst +++ b/clang/docs/LanguageExtensions.rst @@ -13,6 +13,7 @@ Clang Language Extensions BlockLanguageSpec Block-ABI-Apple AutomaticReferenceCounting + PointerAuthentication MatrixTypes Introduction @@ -4244,6 +4245,10 @@ reordering of memory accesses and side effect instructions. Other instructions like simple arithmetic may be reordered around the intrinsic. If you expect to have no reordering at all, use inline assembly instead. +Pointer Authentication +^^ +See :doc:`PointerAuthentication`. + X86/X86-64 Language Extensions -- diff --git a/clang/docs/PointerAuthentication.rst b/clang/docs/PointerAuthentication.rst new file mode 100644 index 000..0ecdfb34e8cf72a --- /dev/null +++ b/clang/docs/PointerAuthentication.rst @@ -0,0 +1,485 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic +protection against exploiting a broad class of memory bugs to take control of +program execution. When adopted consistently in a language ABI, it provides +a form of relatively fine-grained control flow integrity (CFI) check that +resists both return-oriented programming (ROP) and jump-oriented programming +(JOP) attacks. + +While pointer authentication can be implemented purely in software, direct +hardware support (e.g. as provided by Armv8.3 PAuth) can dramatically improve +performance and code size. Similarly, while pointer authentication +can be implemented on any architecture, taking advantage of the (typically) +excess addressing range of a target with 64-bit pointers minimizes the impact +on memory performance and can allow interoperation with existing code (by +disabling pointer authentication dynamically). This document will generally +attempt to present the pointer authentication feature independent of any +hardware implementation or ABI. Considerations that are +implementation-specific are clearly identified throughout. + +Note
[llvm] [clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha updated https://github.com/llvm/llvm-project/pull/65996 >From c4e7c86eb967b4313e19587e33fdc6b50c8cd6a7 Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Wed, 16 Aug 2023 09:17:12 -0700 Subject: [PATCH] [AArch64][PAC] Support and document ptrauth builtins and -fptrauth-intrinsics. This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, in addition to these builtins. Co-Authored-By: Akira Hatanaka Co-Authored-By: John McCall --- clang/docs/LanguageExtensions.rst | 5 + clang/docs/PointerAuthentication.rst | 265 ++ clang/include/clang/Basic/Builtins.def| 8 + clang/include/clang/Basic/DiagnosticGroups.td | 1 + .../clang/Basic/DiagnosticSemaKinds.td| 16 ++ clang/include/clang/Basic/Features.def| 1 + clang/include/clang/Basic/LangOptions.def | 2 + clang/include/clang/Basic/TargetInfo.h| 6 + clang/include/clang/Driver/Options.td | 8 + clang/include/clang/Sema/Sema.h | 2 + clang/lib/Basic/TargetInfo.cpp| 4 + clang/lib/Basic/Targets/AArch64.cpp | 6 + clang/lib/Basic/Targets/AArch64.h | 2 + clang/lib/CodeGen/CGBuiltin.cpp | 67 + clang/lib/Driver/ToolChains/Clang.cpp | 5 + clang/lib/Frontend/CompilerInvocation.cpp | 14 + clang/lib/Headers/CMakeLists.txt | 1 + clang/lib/Headers/module.modulemap| 5 + clang/lib/Headers/ptrauth.h | 167 +++ clang/lib/Sema/SemaChecking.cpp | 182 clang/test/CodeGen/ptrauth-intrinsics.c | 73 + clang/test/Preprocessor/ptrauth_feature.c | 10 + clang/test/Sema/ptrauth-intrinsics-macro.c| 34 +++ clang/test/Sema/ptrauth.c | 126 + llvm/docs/PointerAuth.md | 3 + 25 files changed, 1013 insertions(+) create mode 100644 clang/docs/PointerAuthentication.rst create mode 100644 clang/lib/Headers/ptrauth.h create mode 100644 clang/test/CodeGen/ptrauth-intrinsics.c create mode 100644 clang/test/Preprocessor/ptrauth_feature.c create mode 100644 clang/test/Sema/ptrauth-intrinsics-macro.c create mode 100644 clang/test/Sema/ptrauth.c diff --git a/clang/docs/LanguageExtensions.rst b/clang/docs/LanguageExtensions.rst index 23a7f4f5d5b926..00657e6c9bfe11 100644 --- a/clang/docs/LanguageExtensions.rst +++ b/clang/docs/LanguageExtensions.rst @@ -13,6 +13,7 @@ Clang Language Extensions BlockLanguageSpec Block-ABI-Apple AutomaticReferenceCounting + PointerAuthentication MatrixTypes Introduction @@ -4206,6 +4207,10 @@ reordering of memory accesses and side effect instructions. Other instructions like simple arithmetic may be reordered around the intrinsic. If you expect to have no reordering at all, use inline assembly instead. +Pointer Authentication +^^ +See :doc:`PointerAuthentication`. + X86/X86-64 Language Extensions -- diff --git a/clang/docs/PointerAuthentication.rst b/clang/docs/PointerAuthentication.rst new file mode 100644 index 00..96bcf2cd5fc824 --- /dev/null +++ b/clang/docs/PointerAuthentication.rst @@ -0,0 +1,265 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3 PAuth) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly
[clang-tools-extra] [libc] [openmp] [lld] [compiler-rt] [libcxxabi] [clang] [libcxx] [lldb] [mlir] [flang] [llvm] [llvm] Support IFuncs on Darwin platforms (PR #73686)
https://github.com/ahmedbougacha approved this pull request. Neat, ty! https://github.com/llvm/llvm-project/pull/73686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[lld] [clang] [libcxx] [llvm] [libc] [mlir] [libcxxabi] [openmp] [lldb] [clang-tools-extra] [compiler-rt] [flang] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -2169,8 +2169,11 @@ void AsmPrinter::emitGlobalIFunc(Module , const
GlobalIFunc ) {
MCSymbol *LocalAlias = getSymbolPreferLocal(GI);
if (LocalAlias != Name)
OutStreamer->emitAssignment(LocalAlias, Expr);
- } else if (TM.getTargetTriple().isOSBinFormatMachO() &&
- getIFuncMCSubtargetInfo()) {
+
+return;
+ }
+
+ if (TM.getTargetTriple().isOSBinFormatMachO() && getIFuncMCSubtargetInfo()) {
ahmedbougacha wrote:
oh I meant literally:
```
if (!TM.getTargetTriple().isOSBinFormatMachO() || !getIFuncMCSubtargetInfo())
llvm::report_fatal_error("IFuncs are not supported on this platform");
```
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [libcxxabi] [compiler-rt] [mlir] [openmp] [lldb] [flang] [clang-tools-extra] [libc] [lld] [libcxx] [clang] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -2147,24 +2148,80 @@ void AsmPrinter::emitGlobalIFunc(Module , const
GlobalIFunc ) {
assert(!TM.getTargetTriple().isOSBinFormatXCOFF() &&
"IFunc is not supported on AIX.");
- MCSymbol *Name = getSymbol();
+ auto EmitLinkage = [&](MCSymbol *Sym) {
+if (GI.hasExternalLinkage() || !MAI->getWeakRefDirective())
+ OutStreamer->emitSymbolAttribute(Sym, MCSA_Global);
+else if (GI.hasWeakLinkage() || GI.hasLinkOnceLinkage())
+ OutStreamer->emitSymbolAttribute(Sym, MCSA_WeakReference);
+else
+ assert(GI.hasLocalLinkage() && "Invalid ifunc linkage");
+ };
- if (GI.hasExternalLinkage() || !MAI->getWeakRefDirective())
-OutStreamer->emitSymbolAttribute(Name, MCSA_Global);
- else if (GI.hasWeakLinkage() || GI.hasLinkOnceLinkage())
-OutStreamer->emitSymbolAttribute(Name, MCSA_WeakReference);
- else
-assert(GI.hasLocalLinkage() && "Invalid ifunc linkage");
+ if (TM.getTargetTriple().isOSBinFormatELF()) {
+MCSymbol *Name = getSymbol();
+EmitLinkage(Name);
+OutStreamer->emitSymbolAttribute(Name, MCSA_ELF_TypeIndFunction);
+emitVisibility(Name, GI.getVisibility());
+
+// Emit the directives as assignments aka .set:
+const MCExpr *Expr = lowerConstant(GI.getResolver());
+OutStreamer->emitAssignment(Name, Expr);
+MCSymbol *LocalAlias = getSymbolPreferLocal(GI);
+if (LocalAlias != Name)
+ OutStreamer->emitAssignment(LocalAlias, Expr);
+ } else if (TM.getTargetTriple().isOSBinFormatMachO() &&
ahmedbougacha wrote:
early return with if->fatal_error, for indentation?
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[lldb] [clang] [openmp] [lld] [compiler-rt] [libc] [flang] [libcxxabi] [llvm] [libcxx] [clang-tools-extra] [mlir] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -599,6 +599,26 @@ class AsmPrinter : public MachineFunctionPass {
/// instructions in verbose mode.
virtual void emitImplicitDef(const MachineInstr *MI) const;
+ /// getSubtargetInfo() cannot be used where this is needed because we don't
+ /// have a MachineFunction when we're lowering a GlobalIFunc, and
+ /// getSubtargetInfo requires one. Override the implementation in targets
+ /// that support the Mach-O IFunc lowering.
+ virtual const MCSubtargetInfo *getIFuncMCSubtargetInfo() const {
+return nullptr;
+ }
+
+ virtual void emitMachOIFuncStubBody(Module , const GlobalIFunc ,
+ MCSymbol *LazyPointer) {
ahmedbougacha wrote:
Maybe pass the symbol string directly, since the implementations make their own
symbol references anyway? That way you also don't have to do the awkward
de-mangle/re-mangle dance with the +1
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] [clang] [libcxxabi] [lld] [flang] [openmp] [mlir] [llvm] [libc] [compiler-rt] [clang-tools-extra] [lldb] [llvm] Support IFuncs on Darwin platforms (PR #73686)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/73686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libc] [lld] [clang] [libcxx] [lldb] [mlir] [clang-tools-extra] [libcxxabi] [flang] [llvm] [openmp] [compiler-rt] [llvm] Support IFuncs on Darwin platforms (PR #73686)
https://github.com/ahmedbougacha commented: Only a couple minor comments, LG otherwise, thanks! The Subtarget weirdness is unfortunate but I can't say I have a better alternative https://github.com/llvm/llvm-project/pull/73686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang-tools-extra] [llvm] Support IFuncs on Darwin platforms (PR #73686)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/73686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [llvm] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -1809,6 +1814,255 @@ void AArch64AsmPrinter::emitInstruction(const
MachineInstr *MI) {
EmitToStreamer(*OutStreamer, TmpInst);
}
+void AArch64AsmPrinter::emitGlobalIFunc(Module , const GlobalIFunc ) {
+ if (!TM.getTargetTriple().isOSBinFormatMachO())
+return AsmPrinter::emitGlobalIFunc(M, GI);
ahmedbougacha wrote:
How about having all the lazy/stub symbol machinery in AsmPrinter proper, and
only having target-specific "emit macho stub/helper body" overridable hooks?
I ask because I wondered "when would you have `!MAI->getWeakRefDirective()` for
macho?" and noticed that's from the base anyway. I imagine moving this
wouldn't change that, because this'd still be in a macho-specific bit there.
But at least if the ELF base changes, the macho version would be right there
next to it ;) WDYT?
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang-tools-extra] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -144,7 +144,12 @@ bool CallLowering::lowerCall(MachineIRBuilder ,
const CallBase ,
// Try looking through a bitcast from one function type to another.
// Commonly happens with calls to objc_msgSend().
const Value *CalleeV = CB.getCalledOperand()->stripPointerCasts();
- if (const Function *F = dyn_cast(CalleeV))
+ if (const GlobalIFunc *IF = dyn_cast(CalleeV);
+ IF && MF.getTarget().getTargetTriple().isOSBinFormatMachO()) {
ahmedbougacha wrote:
Heh, I did a double-take on the nesting; maybe embrace the dumber
`isa<>`/`cast<>`? ;)
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang-tools-extra] [llvm] Support IFuncs on Darwin platforms (PR #73686)
@@ -882,8 +882,11 @@ class AsmPrinter : public MachineFunctionPass {
GCMetadataPrinter *getOrCreateGCPrinter(GCStrategy );
void emitGlobalAlias(Module , const GlobalAlias );
- void emitGlobalIFunc(Module , const GlobalIFunc );
+protected:
+ virtual void emitGlobalIFunc(Module , const GlobalIFunc );
ahmedbougacha wrote:
Probably deserves to be with `emitGlobalVariable` or "overridable hooks" above?
(but maybe the hooks can be finer-grained, see later comment)
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] AArch64: add support for currently released Apple CPUs. (PR #73499)
https://github.com/ahmedbougacha approved this pull request. https://github.com/llvm/llvm-project/pull/73499 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -303,6 +303,10 @@ bool Module::directlyUses(const Module *Requested) {
if (!Requested->Parent && Requested->Name == "_Builtin_stddef_max_align_t")
return true;
+ // Anyone is allowed to use our builtin ptrauth.h and its accompanying
module.
+ if (!Requested->Parent && Requested->Name == "ptrauth")
ahmedbougacha wrote:
It’s needed in this patch because this patch introduces the `ptrauth.h` header
file, which wouldn’t be usable from modules without this change.
If you have an alternative fix I’m open to suggestions.
https://github.com/llvm/llvm-project/pull/65996
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha updated https://github.com/llvm/llvm-project/pull/65996: >From fccf0643bd7812301819f5c7fce30d81c6e86a80 Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Wed, 16 Aug 2023 09:17:12 -0700 Subject: [PATCH] [AArch64][PAC] Support and document ptrauth builtins and -fptrauth-intrinsics. This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, in addition to these builtins. Co-Authored-By: Akira Hatanaka Co-Authored-By: John McCall --- clang/docs/LanguageExtensions.rst | 5 + clang/docs/PointerAuthentication.rst | 265 ++ clang/include/clang/Basic/Builtins.def| 8 + clang/include/clang/Basic/DiagnosticGroups.td | 1 + .../clang/Basic/DiagnosticSemaKinds.td| 16 ++ clang/include/clang/Basic/Features.def| 1 + clang/include/clang/Basic/LangOptions.def | 2 + clang/include/clang/Basic/TargetInfo.h| 6 + clang/include/clang/Driver/Options.td | 8 + clang/include/clang/Sema/Sema.h | 2 + clang/lib/Basic/Module.cpp| 4 + clang/lib/Basic/TargetInfo.cpp| 4 + clang/lib/Basic/Targets/AArch64.cpp | 6 + clang/lib/Basic/Targets/AArch64.h | 2 + clang/lib/CodeGen/CGBuiltin.cpp | 67 + clang/lib/Driver/ToolChains/Clang.cpp | 5 + clang/lib/Frontend/CompilerInvocation.cpp | 13 + clang/lib/Headers/CMakeLists.txt | 1 + clang/lib/Headers/module.modulemap| 5 + clang/lib/Headers/ptrauth.h | 167 +++ clang/lib/Sema/SemaChecking.cpp | 182 clang/test/CodeGen/ptrauth-intrinsics.c | 73 + .../module.modulemap | 8 + .../ptrauth-include-from-darwin/ptrauth.h | 1 + .../ptrauth-include-from-darwin/stddef.h | 1 + .../Modules/ptrauth-include-from-darwin.m | 6 + clang/test/Preprocessor/ptrauth_feature.c | 10 + clang/test/Sema/ptrauth-intrinsics-macro.c| 34 +++ clang/test/Sema/ptrauth.c | 126 + llvm/docs/PointerAuth.md | 3 + 30 files changed, 1032 insertions(+) create mode 100644 clang/docs/PointerAuthentication.rst create mode 100644 clang/lib/Headers/ptrauth.h create mode 100644 clang/test/CodeGen/ptrauth-intrinsics.c create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/module.modulemap create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/ptrauth.h create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/stddef.h create mode 100644 clang/test/Modules/ptrauth-include-from-darwin.m create mode 100644 clang/test/Preprocessor/ptrauth_feature.c create mode 100644 clang/test/Sema/ptrauth-intrinsics-macro.c create mode 100644 clang/test/Sema/ptrauth.c diff --git a/clang/docs/LanguageExtensions.rst b/clang/docs/LanguageExtensions.rst index 11cbdca7a268fc3..49a3934d9d082fc 100644 --- a/clang/docs/LanguageExtensions.rst +++ b/clang/docs/LanguageExtensions.rst @@ -13,6 +13,7 @@ Clang Language Extensions BlockLanguageSpec Block-ABI-Apple AutomaticReferenceCounting + PointerAuthentication MatrixTypes Introduction @@ -4157,6 +4158,10 @@ reordering of memory accesses and side effect instructions. Other instructions like simple arithmetic may be reordered around the intrinsic. If you expect to have no reordering at all, use inline assembly instead. +Pointer Authentication +^^ +See :doc:`PointerAuthentication`. + X86/X86-64 Language Extensions -- diff --git a/clang/docs/PointerAuthentication.rst b/clang/docs/PointerAuthentication.rst new file mode 100644 index 000..96bcf2cd5fc824b --- /dev/null +++ b/clang/docs/PointerAuthentication.rst @@ -0,0 +1,265 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. ahmedbougacha wrote: I read "ultimately" here as "boiled down to the important part" (so, e.g., allowing value-preserving conversions between the auth/sign); we could remove the word altogether though! As for "expected", I think that's in opposition to the next sentence, about the unexpected cases where it doesn't actually do that ;) https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -0,0 +1,548 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of program execution. When adopted consistently in a language ABI, it provides a form of relatively fine-grained control flow integrity (CFI) check that resists both return-oriented programming (ROP) and jump-oriented programming (JOP) attacks. + +While pointer authentication can be implemented purely in software, direct hardware support (e.g. as provided by ARMv8.3) can dramatically lower the execution speed and code size costs. Similarly, while pointer authentication can be implemented on any architecture, taking advantage of the (typically) excess addressing range of a target with 64-bit pointers minimizes the impact on memory performance and can allow interoperation with existing code (by disabling pointer authentication dynamically). This document will generally attempt to present the pointer authentication feature independent of any hardware implementation or ABI. Considerations that are implementation-specific are clearly identified throughout. + +Note that there are several different terms in use: + +- **Pointer authentication** is a target-independent language technology. + +- **ARMv8.3** is an AArch64 architecture revision of that provides hardware support for pointer authentication. It is implemented on several shipping processors, including the Apple A12 and later. + +* **arm64e** is a specific ABI for (not yet fully stable) for implementing pointer authentication on ARMv8.3 on certain Apple operating systems. + +This document serves four purposes: + +- It describes the basic ideas of pointer authentication. + +- It documents several language extensions that are useful on targets using pointer authentication. + +- It presents a theory of operation for the security mitigation, describing the basic requirements for correctness, various weaknesses in the mechanism, and ways in which programmers can strengthen its protections (including recommendations for language implementors). + +- It will eventually document the language ABIs currently used for C, C++, Objective-C, and Swift on arm64e, although these are not yet stable on any target. + +Basic Concepts +-- + +The simple address of an object or function is a **raw pointer**. A raw pointer can be **signed** to produce a **signed pointer**. A signed pointer can be then **authenticated** in order to verify that it was **validly signed** and extract the original raw pointer. These terms reflect the most likely implementation technique: computing and storing a cryptographic signature along with the pointer. The security of pointer authentication does not rely on attackers not being able to separately overwrite the signature. + +An **abstract signing key** is a name which refers to a secret key which can used to sign and authenticate pointers. The key value for a particular name is consistent throughout a process. + +A **discriminator** is an arbitrary value used to **diversify** signed pointers so that one validly-signed pointer cannot simply be copied over another. A discriminator is simply opaque data of some implementation-defined size that is included in the signature as a salt. + +Nearly all aspects of pointer authentication use just these two primary operations: + +- ``sign(raw_pointer, key, discriminator)`` produces a signed pointer given a raw pointer, an abstract signing key, and a discriminator. + +- ``auth(signed_pointer, key, discriminator)`` produces a raw pointer given a signed pointer, an abstract signing key, and a discriminator. + +``auth(sign(raw_pointer, key, discriminator), key, discriminator)`` must succeed and produce ``raw_pointer``. ``auth`` applied to a value that was ultimately produced in any other way is expected to immediately halt the program. However, it is permitted for ``auth`` to fail to detect that a signed pointer was not produced in this way, in which case it may return anything; this is what makes pointer authentication a probabilistic mitigation rather than a perfect one. + +There are two secondary operations which are required only to implement certain intrinsics in : + +- ``strip(signed_pointer, key)`` produces a raw pointer given a signed pointer and a key it was presumptively signed with. This is useful for certain kinds of tooling, such as crash backtraces; it should generally not be used in the basic language ABI except in very careful ways. + +- ``sign_generic(value)`` produces a cryptographic signature for arbitrary data, not necessarily a pointer. This is useful for efficiently verifying that non-pointer data has not been tampered with. + +Whenever any of these operations is called for, the key value must be known statically. This is
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
@@ -303,6 +303,10 @@ bool Module::directlyUses(const Module *Requested) {
if (!Requested->Parent && Requested->Name == "_Builtin_stddef_max_align_t")
return true;
+ // Anyone is allowed to use our builtin ptrauth.h and its accompanying
module.
+ if (!Requested->Parent && Requested->Name == "ptrauth")
ahmedbougacha wrote:
Unfortunately this is needed, to match the (compiler-interface-defining)
`ptrauth.h` header file we vend. (specifically this is to allow usage of
`ptrauth.h` from `no_undeclared_interfaces` modules, see ed84df008f609.
https://github.com/llvm/llvm-project/pull/65996
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha labeled https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha review_requested https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha created https://github.com/llvm/llvm-project/pull/65996: This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, as well as these builtins. (Replaces https://reviews.llvm.org/D112941) >From 6d135911787111dff1845a0c55e3d0ec0f280787 Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Mon, 11 Sep 2023 11:41:47 -0700 Subject: [PATCH] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. This defines the basic set of pointer authentication clang builtins (provided in a new header, ptrauth.h), with diagnostics and IRGen support. The availability of the builtins is gated on a new flag, `-fptrauth-intrinsics`. Note that this only includes the basic intrinsics, and notably excludes `ptrauth_sign_constant`, `ptrauth_type_discriminator`, and `ptrauth_string_discriminator`, which need extra logic to be fully supported. This also introduces clang/docs/PointerAuthentication.rst, which describes the ptrauth model in general, as well as these builtins. Co-Authored-By: Akira Hatanaka Co-Authored-By: John McCall --- clang/docs/LanguageExtensions.rst | 5 + clang/docs/PointerAuthentication.rst | 548 ++ clang/include/clang/Basic/Builtins.def| 8 + clang/include/clang/Basic/DiagnosticGroups.td | 1 + .../clang/Basic/DiagnosticSemaKinds.td| 16 + clang/include/clang/Basic/Features.def| 1 + clang/include/clang/Basic/LangOptions.def | 2 + clang/include/clang/Basic/TargetInfo.h| 6 + clang/include/clang/Driver/Options.td | 8 + clang/include/clang/Sema/Sema.h | 2 + clang/lib/Basic/Module.cpp| 4 + clang/lib/Basic/TargetInfo.cpp| 4 + clang/lib/Basic/Targets/AArch64.cpp | 6 + clang/lib/Basic/Targets/AArch64.h | 2 + clang/lib/CodeGen/CGBuiltin.cpp | 67 +++ clang/lib/Driver/ToolChains/Clang.cpp | 5 + clang/lib/Frontend/CompilerInvocation.cpp | 13 + clang/lib/Headers/CMakeLists.txt | 1 + clang/lib/Headers/module.modulemap| 5 + clang/lib/Headers/ptrauth.h | 167 ++ clang/lib/Sema/SemaChecking.cpp | 182 ++ clang/test/CodeGen/ptrauth-intrinsics.c | 73 +++ .../module.modulemap | 8 + .../ptrauth-include-from-darwin/ptrauth.h | 1 + .../ptrauth-include-from-darwin/stddef.h | 1 + .../Modules/ptrauth-include-from-darwin.m | 6 + clang/test/Preprocessor/ptrauth_feature.c | 10 + clang/test/Sema/ptrauth-intrinsics-macro.c| 34 ++ clang/test/Sema/ptrauth.c | 126 llvm/docs/PointerAuth.md | 3 + 30 files changed, 1315 insertions(+) create mode 100644 clang/docs/PointerAuthentication.rst create mode 100644 clang/lib/Headers/ptrauth.h create mode 100644 clang/test/CodeGen/ptrauth-intrinsics.c create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/module.modulemap create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/ptrauth.h create mode 100644 clang/test/Modules/Inputs/ptrauth-include-from-darwin/stddef.h create mode 100644 clang/test/Modules/ptrauth-include-from-darwin.m create mode 100644 clang/test/Preprocessor/ptrauth_feature.c create mode 100644 clang/test/Sema/ptrauth-intrinsics-macro.c create mode 100644 clang/test/Sema/ptrauth.c diff --git a/clang/docs/LanguageExtensions.rst b/clang/docs/LanguageExtensions.rst index 11cbdca7a268fc3..49a3934d9d082fc 100644 --- a/clang/docs/LanguageExtensions.rst +++ b/clang/docs/LanguageExtensions.rst @@ -13,6 +13,7 @@ Clang Language Extensions BlockLanguageSpec Block-ABI-Apple AutomaticReferenceCounting + PointerAuthentication MatrixTypes Introduction @@ -4157,6 +4158,10 @@ reordering of memory accesses and side effect instructions. Other instructions like simple arithmetic may be reordered around the intrinsic. If you expect to have no reordering at all, use inline assembly instead. +Pointer Authentication +^^ +See :doc:`PointerAuthentication`. + X86/X86-64 Language Extensions -- diff --git a/clang/docs/PointerAuthentication.rst b/clang/docs/PointerAuthentication.rst new file mode 100644 index 000..87b8f244a2e4653 --- /dev/null +++ b/clang/docs/PointerAuthentication.rst @@ -0,0 +1,548 @@ +Pointer Authentication
[clang] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)
https://github.com/ahmedbougacha labeled https://github.com/llvm/llvm-project/pull/65996 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 89c94c2 - [clang][Driver] Get darwin -Xarch_ working for subtypes, again.
Author: Ahmed Bougacha
Date: 2022-03-09T18:21:45-08:00
New Revision: 89c94c242c7ddcc700aba6af7243dcac7a9a4ef2
URL:
https://github.com/llvm/llvm-project/commit/89c94c242c7ddcc700aba6af7243dcac7a9a4ef2
DIFF:
https://github.com/llvm/llvm-project/commit/89c94c242c7ddcc700aba6af7243dcac7a9a4ef2.diff
LOG: [clang][Driver] Get darwin -Xarch_ working for subtypes, again.
35ca7d9ddf4 broke 471c4f829934 for -arch flags that don't map 1:1
to the triple arch. This has been broken for the many years since.
It hasn't mattered much since then, mostly because few people use it,
but also because it works for x86_64/i386, armv7/armv7s
don't differ much, arm64 is its own arch, and arm64/arm64_32 have
different arches (and it's a rare combination anyway).
But arm64/arm64e exposes this issue again.
Patch by: Justin Bogner
with some added tests.
Added:
Modified:
clang/lib/Driver/ToolChains/Darwin.cpp
clang/test/Driver/darwin-xarch.c
Removed:
diff --git a/clang/lib/Driver/ToolChains/Darwin.cpp
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 005236c4476f4..a11cd3fbaa71c 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2487,12 +2487,9 @@ DerivedArgList *MachO::TranslateArgs(const
DerivedArgList ,
if (A->getOption().matches(options::OPT_Xarch__)) {
// Skip this argument unless the architecture matches either the
toolchain
// triple arch, or the arch being bound.
- llvm::Triple::ArchType XarchArch =
- tools::darwin::getArchTypeForMachOArchName(A->getValue(0));
- if (!(XarchArch == getArch() ||
-(!BoundArch.empty() &&
- XarchArch ==
- tools::darwin::getArchTypeForMachOArchName(BoundArch
+ StringRef XarchArch = A->getValue(0);
+ if (!(XarchArch == getArchName() ||
+(!BoundArch.empty() && XarchArch == BoundArch)))
continue;
Arg *OriginalArg = A;
diff --git a/clang/test/Driver/darwin-xarch.c
b/clang/test/Driver/darwin-xarch.c
index 3014236f8ccda..0df17fda7b0e3 100644
--- a/clang/test/Driver/darwin-xarch.c
+++ b/clang/test/Driver/darwin-xarch.c
@@ -18,3 +18,32 @@
// RUN: FileCheck --check-prefix=CHECK-ARMV7-LINK < %t %s
//
// CHECK-ARMV7-LINK: ld{{.*}} "-arch" "armv7"{{.*}} "-some-linker-arg"
+
+
+// RUN: %clang -target armv7s-apple-ios7 -### \
+// RUN: -arch armv7 -Xarch_armv7 -DARMV7=1 \
+// RUN: -arch armv7s -Xarch_armv7s -DARMV7S=1 \
+// RUN: -c %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-ARMV7S < %t %s
+//
+// CHECK-ARMV7S: clang{{.*}}" "-cc1" "-triple" "thumbv7-apple-ios7.0.0"
+// CHECK-ARMV7S-NOT: "-D" "ARMV7S=1"
+// CHECK-ARMV7S-SAME: "-D" "ARMV7=1"
+//
+// CHECK-ARMV7S: clang{{.*}}" "-cc1" "-triple" "thumbv7s-apple-ios7.0.0"
+// CHECK-ARMV7S-NOT: "-D" "ARMV7=1"
+// CHECK-ARMV7S-SAME: "-D" "ARMV7S=1"
+
+// RUN: %clang -target arm64-apple-ios14 -### \
+// RUN: -arch arm64 -Xarch_arm64 -DARM64=1 \
+// RUN: -arch arm64e -Xarch_arm64e -DARM64E=1 \
+// RUN: -c %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-ARM64 < %t %s
+//
+// CHECK-ARM64: clang{{.*}}" "-cc1" "-triple" "arm64-apple-ios14.0.0"
+// CHECK-ARM64-NOT: "-D" "ARM64E=1"
+// CHECK-ARM64-SAME: "-D" "ARM64=1"
+//
+// CHECK-ARM64: clang{{.*}}" "-cc1" "-triple" "arm64e-apple-ios14.0.0"
+// CHECK-ARM64-NOT: "-D" "ARM64=1"
+// CHECK-ARM64-SAME: "-D" "ARM64E=1"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] ca9f0ec - [clang] Document objc_unsafeClaimAutoreleasedReturnValue.
Author: Ahmed Bougacha Date: 2022-02-08T14:30:39-08:00 New Revision: ca9f0ec1a30b899ce9df3d2173aa9a295b510509 URL: https://github.com/llvm/llvm-project/commit/ca9f0ec1a30b899ce9df3d2173aa9a295b510509 DIFF: https://github.com/llvm/llvm-project/commit/ca9f0ec1a30b899ce9df3d2173aa9a295b510509.diff LOG: [clang] Document objc_unsafeClaimAutoreleasedReturnValue. This has been added a few years ago but wasn't listed here. Added: Modified: clang/docs/AutomaticReferenceCounting.rst Removed: diff --git a/clang/docs/AutomaticReferenceCounting.rst b/clang/docs/AutomaticReferenceCounting.rst index 9b0b6b86eb11e..5e40fa837b1aa 100644 --- a/clang/docs/AutomaticReferenceCounting.rst +++ b/clang/docs/AutomaticReferenceCounting.rst @@ -2380,8 +2380,10 @@ the current pool, and returns an opaque "handle" to it. If ``value`` is null, this call has no effect. Otherwise, it makes a best effort to hand off ownership of a retain count on the object to a call to :ref:`objc_retainAutoreleasedReturnValue -` for the same object in an -enclosing call frame. If this is not possible, the object is autoreleased as +` (or +:ref:`objc_unsafeClaimAutoreleasedReturnValue +`) for the same object in +an enclosing call frame. If this is not possible, the object is autoreleased as above. Always returns ``value``. @@ -2579,8 +2581,8 @@ Always returns ``value``. If ``value`` is null, this call has no effect. Otherwise, it attempts to accept a hand off of a retain count from a call to :ref:`objc_autoreleaseReturnValue ` on -``value`` in a recently-called function or something it calls. If that fails, -it performs a retain operation exactly like :ref:`objc_retain +``value`` in a recently-called function or something it tail-calls. If that +fails, it performs a retain operation exactly like :ref:`objc_retain `. Always returns ``value``. @@ -2639,3 +2641,21 @@ registration updated to point to ``value``. Returns the value of ``object`` after the call. +.. _arc.runtime.objc_unsafeClaimAutoreleasedReturnValue: + +``id objc_unsafeClaimAutoreleasedReturnValue(id value);`` +- + +*Precondition:* ``value`` is null or a pointer to a valid object. + +If ``value`` is null, this call has no effect. Otherwise, it attempts to +accept a hand off of a retain count from a call to +:ref:`objc_autoreleaseReturnValue ` on +``value`` in a recently-called function or something it tail-calls (in a manner +similar to :ref:`objc_retainAutoreleasedReturnValue +`). If that succeeds, +it performs a release operation exactly like :ref:`objc_release +`. If the handoff fails, this call has no effect. + +Always returns ``value``. + ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
