Commit Graph

3052 Commits

Author SHA1 Message Date
Zequan Wu 901f74ca69 [gn build] port c8daf4a707 (check-lldb)
Reviewed By: thakis

Differential Revision: https://reviews.llvm.org/D133718
2022-09-13 11:17:01 -07:00
Zequan Wu 08d4d7cb8d [gn build] port a3172df59c (check-lldb)
https://reviews.llvm.org/rGa3172df59c32aac48c113eb7d6a1324aaa95c474 breaks
check-lldb gn build.

Reviewed By: thakis

Differential Revision: https://reviews.llvm.org/D133604
2022-09-13 10:52:56 -07:00
Nico Weber 15e2e34097 [gn build] port 30578c0856 2022-09-13 10:48:48 -04:00
Nico Weber 0a40d7c27a [gn build] port a85e4aa37d 2022-09-12 21:02:02 -04:00
Nico Weber 4e08f5f0c4 [gn build] port 7d80b94ca3 (llvm-remarkutil) 2022-09-12 19:19:23 -04:00
LLVM GN Syncbot aad516ef0b [gn build] Port cf72dddaef 2022-09-12 19:46:19 +00:00
Nico Weber 90b36e6be5 [gn build] port 346856dc6c (or port 4d50a39240 more?) 2022-09-12 15:45:42 -04:00
Nico Weber 28890b7bab [gn build] port 1a608cfb5c 2022-09-09 19:18:05 -04:00
Nico Weber 27613a1038 [gn build] port 48506fbbbf (Mach-O-Fileset) 2022-09-09 19:18:05 -04:00
Nico Weber 30c30d7fc1 [gn build] port 4d50a39240 (llvm-exegesis multi-target)
Also ports follow-up 5a425b0b2f (I'm getting linker errors without it).
2022-09-09 15:04:47 -04:00
Nico Weber aee094fb8b [gn build] port 5e0464e38b (lld test zstd) 2022-09-09 14:48:26 -04:00
Nico Weber 5dd87a31fd [gn build] port a0365abad8 2022-09-08 06:28:45 -04:00
LLVM GN Syncbot eaf0986b18 [gn build] Port 97c2220565 2022-09-07 23:00:40 +00:00
LLVM GN Syncbot bee10b07c3 [gn build] Port 3e7350f317 2022-09-07 23:00:39 +00:00
Nico Weber cce2947952 [gn build] port aa484c90cf 2022-09-07 18:55:07 -04:00
Nico Weber 811688d5a3 [gn build] port e321c8dd2c 2022-09-07 18:52:06 -04:00
LLVM GN Syncbot f2059dfb38 [gn build] Port e5d2d3eafb 2022-09-07 16:59:10 +00:00
Nico Weber 7bace6f8e6 [gn build] port 5dbc7cf7ca 2022-09-06 11:39:07 -04:00
LLVM GN Syncbot 4ce3848038 [gn build] Port 9823d42557 2022-09-06 11:10:44 +00:00
LLVM GN Syncbot 41c79d0b6d [gn build] Port 2d52c6bfae 2022-09-05 14:41:45 +00:00
LLVM GN Syncbot 8f33a3abb3 [gn build] Port d5e26775d0 2022-09-05 10:39:22 +00:00
LLVM GN Syncbot 1553179e34 [gn build] Port a46154cb1c 2022-09-04 21:07:13 +00:00
LLVM GN Syncbot e3018e4a4f [gn build] Port bc8fd9c633 2022-09-03 02:43:17 +00:00
LLVM GN Syncbot 211817d3be [gn build] Port 3a49cffe3a 2022-09-03 02:22:45 +00:00
LLVM GN Syncbot 055721ff75 [gn build] Port 30adaa730c 2022-09-02 19:47:21 +00:00
LLVM GN Syncbot c0433f91d3 [gn build] Port f6b66cbc7d 2022-09-01 18:01:38 +00:00
LLVM GN Syncbot f252b8477e [gn build] Port d931ac9e27 2022-09-01 10:19:04 +00:00
LLVM GN Syncbot 3622e9bea0 [gn build] Port 74c8d9d5fc 2022-08-31 18:52:31 +00:00
Nico Weber 068fe0724d [gn build] port d45c04da7c (TestingADTTests) 2022-08-31 14:15:23 -04:00
LLVM GN Syncbot 1830302b3f [gn build] Port c9033eeb2e 2022-08-31 17:02:52 +00:00
LLVM GN Syncbot 9eec2ac1d1 [gn build] Port ea9ac3519c 2022-08-30 22:53:54 +00:00
Alexey Baturo f8b71a307e [RISC-V][HWASAN] Add tag mismatch routines for HWASAN required for RISC-V
Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D131341
2022-08-28 19:42:08 +03:00
LLVM GN Syncbot a5857bd21f [gn build] Port 82e893c47c 2022-08-26 19:20:51 +00:00
Nico Weber cb0644b1cc [gn build] port 47166968db (no more clang-offload-wrapper) 2022-08-26 15:11:45 -04:00
LLVM GN Syncbot df46c78078 [gn build] Port 56c54cf66b 2022-08-26 11:23:06 +00:00
LLVM GN Syncbot 66f180edd7 [gn build] Port 3e39b27101 2022-08-26 11:23:05 +00:00
Nico Weber 217eb9f75a [gn build] port bb26ebb4d1 2022-08-26 07:22:35 -04:00
LLVM GN Syncbot 0355a54a2d [gn build] Port 48506fbbbf 2022-08-25 22:25:21 +00:00
Nico Weber 58d630fbfa Revert "[gn build] port bc39d7bdd4 (libclang.map -> libclang.exports)"
This reverts commit 94c00c10e8.
bc39d7bdd4 was reverted in 0f28d48566.
2022-08-25 07:08:44 -04:00
LLVM GN Syncbot e7796c9673 [gn build] Port 5ce4c9aa04 2022-08-25 01:34:14 +00:00
Nico Weber d83a3394b6 [gn build] port 5ce4c9aa04 2022-08-24 21:33:56 -04:00
Sami Tolvanen cff5bef948 KCFI sanitizer
The KCFI sanitizer, enabled with `-fsanitize=kcfi`, implements a
forward-edge control flow integrity scheme for indirect calls. It
uses a !kcfi_type metadata node to attach a type identifier for each
function and injects verification code before indirect calls.

Unlike the current CFI schemes implemented in LLVM, KCFI does not
require LTO, does not alter function references to point to a jump
table, and never breaks function address equality. KCFI is intended
to be used in low-level code, such as operating system kernels,
where the existing schemes can cause undue complications because
of the aforementioned properties. However, unlike the existing
schemes, KCFI is limited to validating only function pointers and is
not compatible with executable-only memory.

KCFI does not provide runtime support, but always traps when a
type mismatch is encountered. Users of the scheme are expected
to handle the trap. With `-fsanitize=kcfi`, Clang emits a `kcfi`
operand bundle to indirect calls, and LLVM lowers this to a
known architecture-specific sequence of instructions for each
callsite to make runtime patching easier for users who require this
functionality.

A KCFI type identifier is a 32-bit constant produced by taking the
lower half of xxHash64 from a C++ mangled typename. If a program
contains indirect calls to assembly functions, they must be
manually annotated with the expected type identifiers to prevent
errors. To make this easier, Clang generates a weak SHN_ABS
`__kcfi_typeid_<function>` symbol for each address-taken function
declaration, which can be used to annotate functions in assembly
as long as at least one C translation unit linked into the program
takes the function address. For example on AArch64, we might have
the following code:

```
.c:
  int f(void);
  int (*p)(void) = f;
  p();

.s:
  .4byte __kcfi_typeid_f
  .global f
  f:
    ...
```

Note that X86 uses a different preamble format for compatibility
with Linux kernel tooling. See the comments in
`X86AsmPrinter::emitKCFITypeId` for details.

As users of KCFI may need to locate trap locations for binary
validation and error handling, LLVM can additionally emit the
locations of traps to a `.kcfi_traps` section.

Similarly to other sanitizers, KCFI checking can be disabled for a
function with a `no_sanitize("kcfi")` function attribute.

Relands 67504c9549 with a fix for
32-bit builds.

Reviewed By: nickdesaulniers, kees, joaomoreira, MaskRay

Differential Revision: https://reviews.llvm.org/D119296
2022-08-24 22:41:38 +00:00
LLVM GN Syncbot fafc6f9985 [gn build] Port 91389000ab 2022-08-24 21:45:56 +00:00
Sami Tolvanen a79060e275 Revert "KCFI sanitizer"
This reverts commit 67504c9549 as using
PointerEmbeddedInt to store 32 bits breaks 32-bit arm builds.
2022-08-24 19:30:13 +00:00
Sami Tolvanen 67504c9549 KCFI sanitizer
The KCFI sanitizer, enabled with `-fsanitize=kcfi`, implements a
forward-edge control flow integrity scheme for indirect calls. It
uses a !kcfi_type metadata node to attach a type identifier for each
function and injects verification code before indirect calls.

Unlike the current CFI schemes implemented in LLVM, KCFI does not
require LTO, does not alter function references to point to a jump
table, and never breaks function address equality. KCFI is intended
to be used in low-level code, such as operating system kernels,
where the existing schemes can cause undue complications because
of the aforementioned properties. However, unlike the existing
schemes, KCFI is limited to validating only function pointers and is
not compatible with executable-only memory.

KCFI does not provide runtime support, but always traps when a
type mismatch is encountered. Users of the scheme are expected
to handle the trap. With `-fsanitize=kcfi`, Clang emits a `kcfi`
operand bundle to indirect calls, and LLVM lowers this to a
known architecture-specific sequence of instructions for each
callsite to make runtime patching easier for users who require this
functionality.

A KCFI type identifier is a 32-bit constant produced by taking the
lower half of xxHash64 from a C++ mangled typename. If a program
contains indirect calls to assembly functions, they must be
manually annotated with the expected type identifiers to prevent
errors. To make this easier, Clang generates a weak SHN_ABS
`__kcfi_typeid_<function>` symbol for each address-taken function
declaration, which can be used to annotate functions in assembly
as long as at least one C translation unit linked into the program
takes the function address. For example on AArch64, we might have
the following code:

```
.c:
  int f(void);
  int (*p)(void) = f;
  p();

.s:
  .4byte __kcfi_typeid_f
  .global f
  f:
    ...
```

Note that X86 uses a different preamble format for compatibility
with Linux kernel tooling. See the comments in
`X86AsmPrinter::emitKCFITypeId` for details.

As users of KCFI may need to locate trap locations for binary
validation and error handling, LLVM can additionally emit the
locations of traps to a `.kcfi_traps` section.

Similarly to other sanitizers, KCFI checking can be disabled for a
function with a `no_sanitize("kcfi")` function attribute.

Reviewed By: nickdesaulniers, kees, joaomoreira, MaskRay

Differential Revision: https://reviews.llvm.org/D119296
2022-08-24 18:52:42 +00:00
LLVM GN Syncbot ab8fcd5ab0 [gn build] Port 134d017b88 2022-08-23 11:31:54 +00:00
LLVM GN Syncbot 684e71eef2 [gn build] Port 15b65bcd65 2022-08-23 05:49:48 +00:00
Nico Weber 4a2c8dcc17 [gn build] port e78208f082 2022-08-22 21:46:36 -04:00
Kazu Hirata 36357c967c Remove llvm::is_trivially_copyable (NFC)
This patch removes llvm::is_trivially_copyable as it seems to be dead.
Once I remove it, HAVE_STD_IS_TRIVIALLY_COPYABLE has no users, so this
patch removes the macro also.

The comment on llvm::is_trivially_copyable mentions GCC 4.9, but note
that we now require GCC 7.1 or higher.

Differential Revision: https://reviews.llvm.org/D132328
2022-08-21 10:39:19 -07:00
Nico Weber 804d4594cb [gn build] Fix oversight in 3adda398ce 2022-08-20 13:39:45 -04:00