Commit Graph

121 Commits

Author SHA1 Message Date
Dimitry Andric
07577dfe2e Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 (branches/release_60 r324090).

This introduces retpoline support, with the -mretpoline flag.  The
upstream initial commit message (r323155 by Chandler Carruth) contains
quite a bit of explanation.  Quoting:

  Introduce the "retpoline" x86 mitigation technique for variant #2 of
  the speculative execution vulnerabilities disclosed today,
  specifically identified by CVE-2017-5715, "Branch Target Injection",
  and is one of the two halves to Spectre.

  Summary:
  First, we need to explain the core of the vulnerability. Note that
  this is a very incomplete description, please see the Project Zero
  blog post for details:
  https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

  The basis for branch target injection is to direct speculative
  execution of the processor to some "gadget" of executable code by
  poisoning the prediction of indirect branches with the address of
  that gadget. The gadget in turn contains an operation that provides a
  side channel for reading data. Most commonly, this will look like a
  load of secret data followed by a branch on the loaded value and then
  a load of some predictable cache line. The attacker then uses timing
  of the processors cache to determine which direction the branch took
  *in the speculative execution*, and in turn what one bit of the
  loaded value was. Due to the nature of these timing side channels and
  the branch predictor on Intel processors, this allows an attacker to
  leak data only accessible to a privileged domain (like the kernel)
  back into an unprivileged domain.

  The goal is simple: avoid generating code which contains an indirect
  branch that could have its prediction poisoned by an attacker. In
  many cases, the compiler can simply use directed conditional branches
  and a small search tree. LLVM already has support for lowering
  switches in this way and the first step of this patch is to disable
  jump-table lowering of switches and introduce a pass to rewrite
  explicit indirectbr sequences into a switch over integers.

  However, there is no fully general alternative to indirect calls. We
  introduce a new construct we call a "retpoline" to implement indirect
  calls in a non-speculatable way. It can be thought of loosely as a
  trampoline for indirect calls which uses the RET instruction on x86.
  Further, we arrange for a specific call->ret sequence which ensures
  the processor predicts the return to go to a controlled, known
  location. The retpoline then "smashes" the return address pushed onto
  the stack by the call with the desired target of the original
  indirect call. The result is a predicted return to the next
  instruction after a call (which can be used to trap speculative
  execution within an infinite loop) and an actual indirect branch to
  an arbitrary address.

  On 64-bit x86 ABIs, this is especially easily done in the compiler by
  using a guaranteed scratch register to pass the target into this
  device.  For 32-bit ABIs there isn't a guaranteed scratch register
  and so several different retpoline variants are introduced to use a
  scratch register if one is available in the calling convention and to
  otherwise use direct stack push/pop sequences to pass the target
  address.

  This "retpoline" mitigation is fully described in the following blog
  post: https://support.google.com/faqs/answer/7625886

  We also support a target feature that disables emission of the
  retpoline thunk by the compiler to allow for custom thunks if users
  want them.  These are particularly useful in environments like
  kernels that routinely do hot-patching on boot and want to hot-patch
  their thunk to different code sequences. They can write this custom
  thunk and use `-mretpoline-external-thunk` *in addition* to
  `-mretpoline`. In this case, on x86-64 thu thunk names must be:
  ```
    __llvm_external_retpoline_r11
  ```
  or on 32-bit:
  ```
    __llvm_external_retpoline_eax
    __llvm_external_retpoline_ecx
    __llvm_external_retpoline_edx
    __llvm_external_retpoline_push
  ```
  And the target of the retpoline is passed in the named register, or in
  the case of the `push` suffix on the top of the stack via a `pushl`
  instruction.

  There is one other important source of indirect branches in x86 ELF
  binaries: the PLT. These patches also include support for LLD to
  generate PLT entries that perform a retpoline-style indirection.

  The only other indirect branches remaining that we are aware of are
  from precompiled runtimes (such as crt0.o and similar). The ones we
  have found are not really attackable, and so we have not focused on
  them here, but eventually these runtimes should also be replicated for
  retpoline-ed configurations for completeness.

  For kernels or other freestanding or fully static executables, the
  compiler switch `-mretpoline` is sufficient to fully mitigate this
  particular attack. For dynamic executables, you must compile *all*
  libraries with `-mretpoline` and additionally link the dynamic
  executable and all shared libraries with LLD and pass `-z
  retpolineplt` (or use similar functionality from some other linker).
  We strongly recommend also using `-z now` as non-lazy binding allows
  the retpoline-mitigated PLT to be substantially smaller.

  When manually apply similar transformations to `-mretpoline` to the
  Linux kernel we observed very small performance hits to applications
  running typic al workloads, and relatively minor hits (approximately
  2%) even for extremely syscall-heavy applications. This is largely
  due to the small number of indirect branches that occur in
  performance sensitive paths of the kernel.

  When using these patches on statically linked applications,
  especially C++ applications, you should expect to see a much more
  dramatic performance hit. For microbenchmarks that are switch,
  indirect-, or virtual-call heavy we have seen overheads ranging from
  10% to 50%.

  However, real-world workloads exhibit substantially lower performance
  impact. Notably, techniques such as PGO and ThinLTO dramatically
  reduce the impact of hot indirect calls (by speculatively promoting
  them to direct calls) and allow optimized search trees to be used to
  lower switches. If you need to deploy these techniques in C++
  applications, we *strongly* recommend that you ensure all hot call
  targets are statically linked (avoiding PLT indirection) and use both
  PGO and ThinLTO. Well tuned servers using all of these techniques saw
  5% - 10% overhead from the use of retpoline.

  We will add detailed documentation covering these components in
  subsequent patches, but wanted to make the core functionality
  available as soon as possible. Happy for more code review, but we'd
  really like to get these patches landed and backported ASAP for
  obvious reasons. We're planning to backport this to both 6.0 and 5.0
  release streams and get a 5.0 release with just this cherry picked
  ASAP for distros and vendors.

  This patch is the work of a number of people over the past month:
  Eric, Reid, Rui, and myself. I'm mailing it out as a single commit
  due to the time sensitive nature of landing this and the need to
  backport it. Huge thanks to everyone who helped out here, and
  everyone at Intel who helped out in discussions about how to craft
  this. Also, credit goes to Paul Turner (at Google, but not an LLVM
  contributor) for much of the underlying retpoline design.

  Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer

  Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits

  Differential Revision: https://reviews.llvm.org/D41723

MFC after:	3 months
X-MFC-With:	r327952
PR:		224669
2018-02-02 22:28:12 +00:00
Dimitry Andric
842d113b5c Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 (branches/release_60 r323948).

MFC after:	3 months
X-MFC-With:	r327952
PR:		224669
2018-02-01 21:41:15 +00:00
Ed Maste
e5c2ece714 Pull in r322131 from upstream llvm trunk (by Rafael Espíndola):
Use a MCExpr for the size of MCFillFragment.

  This allows the size to be found during ralaxation. This fixes
  [LLVM] pr35858.

Requested by:	royger
2018-01-30 16:43:20 +00:00
Ed Maste
00da656e30 Pull in r322108 from upstream llvm trunk (by Rafael Espíndola):
Make one of the emitFill methods non virtual. NFC.

  This is just preparatory work to fix [LLVM] PR35858.
2018-01-30 16:41:38 +00:00
Dimitry Andric
042b1c2ef5 Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 (branches/release_60 r323338).

MFC after:	3 months
X-MFC-With:	r327952
PR:		224669
2018-01-24 22:35:00 +00:00
Dimitry Andric
782f2e69ab Pull in r321994 from upstream llvm trunk (by Alexey Bataev):
[SLP] Fix PR35777: Incorrect handling of aggregate values.

  Summary:
  Fixes the bug with incorrect handling of InsertValue|InsertElement
  instrucions in SLP vectorizer. Currently, we may use incorrect
  ExtractElement instructions as the operands of the original
  InsertValue|InsertElement instructions.

  Reviewers: mkuper, hfinkel, RKSimon, spatel

  Subscribers: llvm-commits

  Differential Revision: https://reviews.llvm.org/D41767

This should fix "Invalid InsertValueInst operands!" errors when building
certain parts of editors/libreoffice.

Reported by:	jbeich
PR:		225086
2018-01-12 18:19:14 +00:00
Dimitry Andric
30785c0e2b Merge llvm, clang, lld, lldb, compiler-rt and libc++ release_60 r321788,
update build glue and version numbers.
2018-01-06 23:44:14 +00:00
Dimitry Andric
fe4fed2e4d Merge llvm, clang, lld, lldb, compiler-rt and libc++ trunk r321545,
update build glue and version numbers, add new intrinsics headers, and
update OptionalObsoleteFiles.inc.
2017-12-29 00:56:15 +00:00
Dimitry Andric
da09e106ef Merge llvm trunk r321414 to contrib/llvm. 2017-12-24 01:04:58 +00:00
Dimitry Andric
2cab237b5d Merge llvm trunk r321017 to contrib/llvm. 2017-12-20 14:16:56 +00:00
Dimitry Andric
d4419f6fa8 Upgrade our copies of clang, llvm, lldb and libc++ to r319231 from the
upstream release_50 branch.  This corresponds to 5.0.1 rc2.

MFC after:	2 weeks
2017-12-03 12:14:34 +00:00
Dimitry Andric
3ea909cc76 Upgrade our copies of clang, llvm, lldb and compiler-rt to r312293 from
the upstream release_50 branch.  This corresponds to 5.0.0 rc4.

As of this version, the cad/stepcode port should now compile in a more
reasonable time on i386 (see bug 221836 for more information).

PR:		221836
MFC after:	2 months
X-MFC-with:	r321369
2017-09-01 18:53:36 +00:00
Dimitry Andric
0fa4377182 Upgrade our copies of clang, llvm, lldb and compiler-rt to r311606 from
the upstream release_50 branch.

As of this version, lib/msun's trig test should also work correctly
again (see bug 220989 for more information).

PR:		220989
MFC after:	2 months
X-MFC-with:	r321369
2017-08-24 20:19:27 +00:00
Dimitry Andric
0554abf0e0 Upgrade our copies of clang, llvm, lld and libc++ to r311219 from the
upstream release_50 branch.

MFC after:	2 months
X-MFC-with:	r321369
2017-08-21 07:03:02 +00:00
Dimitry Andric
9dc417c32b Upgrade our copies of clang, llvm and libc++ to r310316 from the
upstream release_50 branch.

MFC after:	2 months
X-MFC-with:	r321369
2017-08-09 17:32:39 +00:00
Dimitry Andric
37cd60a321 Upgrade our copies of clang, llvm, lld and lldb to r309439 from the
upstream release_50 branch.  This is just after upstream's 5.0.0-rc1.

MFC after:	2 months
X-MFC-with:	r321369
2017-07-30 18:01:34 +00:00
Dimitry Andric
b40b48b876 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r308421, and update
build glue.
2017-07-19 19:41:41 +00:00
Dimitry Andric
c439438675 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r307894, and update
build glue.
2017-07-13 21:58:45 +00:00
Dimitry Andric
a580b01494 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r306956, and update
build glue.
2017-07-02 11:41:15 +00:00
Dimitry Andric
edd7eaddc8 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r306325, and update
build glue.
2017-06-27 06:40:39 +00:00
Dimitry Andric
24d58133b7 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r305575, and update
build glue.
2017-06-17 00:09:34 +00:00
Dimitry Andric
db17bf38c5 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r305145, and update
build glue.
2017-06-10 19:17:14 +00:00
Dimitry Andric
6d97bb297c Merge llvm, clang, lld, lldb, compiler-rt and libc++ r304659, and update
build glue.
2017-06-03 18:18:34 +00:00
Dimitry Andric
f9448bf33f Merge llvm, clang, lld, lldb, compiler-rt and libc++ r304460, and update
build glue.
2017-06-01 22:47:02 +00:00
Dimitry Andric
89cb50c933 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r304222, and update
build glue.
2017-05-30 19:24:09 +00:00
Dimitry Andric
302affcb04 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r304149, and update
build glue.
2017-05-29 22:09:23 +00:00
Dimitry Andric
d8866befb8 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r303571, and update
build glue.
2017-05-22 21:17:44 +00:00
Dimitry Andric
60ff8e32a5 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r303291, and update
build glue.
2017-05-18 18:33:33 +00:00
Dimitry Andric
5517e702c0 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r303197, and update
build glue.
2017-05-16 21:50:29 +00:00
Dimitry Andric
0f5676f432 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r302418, and update
build glue.
2017-05-08 19:20:55 +00:00
Dimitry Andric
f37b6182a5 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r302069, and update
build glue (preliminary, not all option combinations work yet).
2017-05-03 21:54:55 +00:00
Dimitry Andric
51690af2a4 Merge llvm, clang, lld, lldb, compiler-rt and libc++ r301441, and update
build glue.
2017-04-26 22:33:09 +00:00
Dimitry Andric
6bc11b1414 Merge llvm, clang, lld and lldb trunk r300890, and update build glue. 2017-04-20 21:48:54 +00:00
Dimitry Andric
7a7e605503 Merge llvm trunk r300422 and resolve conflicts. 2017-04-16 16:25:46 +00:00
Dimitry Andric
bc93f188f6 Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r296202, and update build glue.
2017-02-25 15:00:57 +00:00
Dimitry Andric
2bcad0d8d6 Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r295380, and update build glue.
2017-02-17 20:07:35 +00:00
Dimitry Andric
5ca5951e31 Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r294803, and update build glue.
2017-02-11 13:58:05 +00:00
Dimitry Andric
077e1117dc Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r293807, and update build glue.
2017-02-01 21:57:07 +00:00
Dimitry Andric
98221d2e7e Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r293443, and update build glue.
2017-01-29 21:56:47 +00:00
Dimitry Andric
9b1870035a Pull in r292133 from upstream llvm trunk (by Hal Finkel):
Fix use-after-free bug in AffectedValueCallbackVH::allUsesReplacedWith

  When transferring affected values in the cache from an old value,
  identified by the value of the current callback, to the specified new
  value we might need to insert a new entry into the DenseMap which
  constitutes the cache. Doing so might delete the current callback
  object. Move the copying logic into a new function, a member of the
  assumption cache itself, so that we don't run into UB should the
  callback handle itself be removed mid-copy.

  Differential Revision: https://reviews.llvm.org/D28749

This should fix crashes when building lld (as part of the llvmXY ports).

Reported by:	jbeich
PR:		216117
2017-01-16 19:53:18 +00:00
Dimitry Andric
f1a29dd344 Merge llvm, clang, lld and lldb release_40 branch r292009. Also update
build glue.
2017-01-14 22:12:13 +00:00
Dimitry Andric
24e2fe98d0 Merge llvm, clang, lld and lldb trunk r291476. 2017-01-09 22:32:19 +00:00
Dimitry Andric
95ec533a1d Merge llvm, clang, lld and lldb trunk r291274, and resolve conflicts. 2017-01-06 20:24:06 +00:00
Dimitry Andric
e466241c2a Merge llvm, clang, lld and lldb trunk r291015, and resolve conflicts. 2017-01-04 22:29:00 +00:00
Dimitry Andric
8e0f8b8c96 Merge llvm, clang, lld and lldb trunk r291012, and resolve conflicts. 2017-01-04 22:19:42 +00:00
Dimitry Andric
d88c1a5a57 Update llvm to trunk r290819 and resolve conflicts. 2017-01-02 21:25:48 +00:00
Dimitry Andric
4dcfa14438 Update llvm, clang, lld and lldb to release_39 branch r288513. 2016-12-02 19:36:28 +00:00
Dimitry Andric
f41fbc90dc Update llvm, clang, lld and lldb to release_39 branch r287912. 2016-11-26 01:02:53 +00:00
Dimitry Andric
82d50f9201 Pull in r280350 from upstream llvm trunk (by Hal Finkel):
Add ISD::EH_DWARF_CFA, simplify @llvm.eh.dwarf.cfa on Mips, fix on
  PowerPC

  LLVM has an @llvm.eh.dwarf.cfa intrinsic, used to lower the
  GCC-compatible __builtin_dwarf_cfa() builtin. As pointed out in
  PR26761, this is currently broken on PowerPC (and likely on ARM as
  well). Currently, @llvm.eh.dwarf.cfa is lowered using:

    ADD(FRAMEADDR, FRAME_TO_ARGS_OFFSET)

  where FRAME_TO_ARGS_OFFSET defaults to the constant zero. On x86,
  FRAME_TO_ARGS_OFFSET is lowered to 2*SlotSize. This setup, however,
  does not work for PowerPC. Because of the way that the stack layout
  works, the canonical frame address is not exactly (FRAMEADDR +
  FRAME_TO_ARGS_OFFSET) on PowerPC (there is a lower save-area offset
  as well), so it is not just a matter of implementing
  FRAME_TO_ARGS_OFFSET for PowerPC (unless we redefine its semantics --
  We can do that, since it is currently used only for
  @llvm.eh.dwarf.cfa lowering, but the better to directly lower the CFA
  construct itself (since it can be easily represented as a
  fixed-offset FrameIndex)). Mips currently does this, but by using a
  custom lowering for ADD that specifically recognizes the (FRAMEADDR,
  FRAME_TO_ARGS_OFFSET) pattern.

  This change introduces a ISD::EH_DWARF_CFA node, which by default
  expands using the existing logic, but can be directly lowered by the
  target. Mips is updated to use this method (which simplifies its
  implementation, and I suspect makes it more robust), and updates
  PowerPC to do the same.

  Fixes PR26761.

  Differential Revision: https://reviews.llvm.org/D24038
2016-09-10 16:11:42 +00:00
Dimitry Andric
fccc5558f5 Update llvm to release_39 branch r279477. 2016-08-24 17:43:08 +00:00