[llvm-branch-commits] [llvm-branch] r323948 - releasenotes: fix a version nbr

[Hans Wennborg via llvm-branch-commits]

Author: hans
Date: Thu Feb  1 01:21:21 2018
New Revision: 323948

URL: http://llvm.org/viewvc/llvm-project?rev=323948&view=rev
Log:
releasenotes: fix a version nbr

Modified:
llvm/branches/release_60/docs/ReleaseNotes.rst

Modified: llvm/branches/release_60/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/llvm/branches/release_60/docs/ReleaseNotes.rst?rev=323948&r1=323947&r2=323948&view=diff
==
--- llvm/branches/release_60/docs/ReleaseNotes.rst (original)
+++ llvm/branches/release_60/docs/ReleaseNotes.rst Thu Feb  1 01:21:21 2018
@@ -15,7 +15,7 @@ Introduction
 
 
 This document contains the release notes for the LLVM Compiler Infrastructure,
-release 5.0.0.  Here we describe the status of LLVM, including major 
improvements
+release 6.0.0.  Here we describe the status of LLVM, including major 
improvements
 from the previous release, improvements in various subprojects of LLVM, and
 some of the current users of the code.  All LLVM releases may be downloaded
 from the `LLVM releases web site `_.


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

Re: [llvm-branch-commits] [cfe-branch] r323179 - [ReleaseNotes] Mention OpenMP Tools Interface in runtime library

[Hans Wennborg via llvm-branch-commits]

As far as I understand, this doesn't actually work on Windows. Should we
update the text?

On Tue, Jan 23, 2018 at 8:50 AM, Jonas Hahnfeld via llvm-branch-commits <
llvm-branch-commits@lists.llvm.org> wrote:

> Author: hahnfeld
> Date: Mon Jan 22 23:50:11 2018
> New Revision: 323179
>
> URL: http://llvm.org/viewvc/llvm-project?rev=323179&view=rev
> Log:
> [ReleaseNotes] Mention OpenMP Tools Interface in runtime library
>
> The OpenMP runtime has no dedicated Release Notes, so add it to Clang's
> section about OpenMP.
>
> Differential Revision: https://reviews.llvm.org/D42352
>
>
> Modified:
> cfe/branches/release_60/docs/ReleaseNotes.rst
>
> Modified: cfe/branches/release_60/docs/ReleaseNotes.rst
> URL: http://llvm.org/viewvc/llvm-project/cfe/branches/release_
> 60/docs/ReleaseNotes.rst?rev=323179&r1=323178&r2=323179&view=diff
> 
> ==
> --- cfe/branches/release_60/docs/ReleaseNotes.rst (original)
> +++ cfe/branches/release_60/docs/ReleaseNotes.rst Mon Jan 22 23:50:11 2018
> @@ -231,6 +231,13 @@ OpenMP Support in Clang
>  - Added support for `reduction`-based clauses on `task`-based directives
> from
>upcoming OpenMP 5.0.
>
> +- The LLVM OpenMP runtime `libomp` now supports the OpenMP Tools
> Interface (OMPT)
> +  on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS. If you
> observe
> +  a measurable performance impact on one of your applications without a
> tool
> +  attached, please rebuild the runtime library with
> `-DLIBOMP_OMPT_SUPPORT=OFF` and
> +  file a bug at `LLVM's Bugzilla `_ or send a
> message to the
> +  `OpenMP development list  bin/mailman/listinfo/openmp-dev>`_.
> +
>  Internal API Changes
>  
>
>
>
> ___
> llvm-branch-commits mailing list
> llvm-branch-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
>
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

Re: [llvm-branch-commits] [cfe-branch] r323179 - [ReleaseNotes] Mention OpenMP Tools Interface in runtime library

[Jonas Hahnfeld via llvm-branch-commits]

I think it actually works _if_ you get Clang to link to the right 
runtime library... Adding Joachim and Olga who have been working on this 
lately.


Am 2018-02-01 10:26, schrieb Hans Wennborg:

As far as I understand, this doesn't actually work on Windows. Should
we update the text?

On Tue, Jan 23, 2018 at 8:50 AM, Jonas Hahnfeld via
llvm-branch-commits  wrote:


Author: hahnfeld
Date: Mon Jan 22 23:50:11 2018
New Revision: 323179

URL: http://llvm.org/viewvc/llvm-project?rev=323179&view=rev [1]
Log:
[ReleaseNotes] Mention OpenMP Tools Interface in runtime library

The OpenMP runtime has no dedicated Release Notes, so add it to
Clang's
section about OpenMP.

Differential Revision: https://reviews.llvm.org/D42352 [2]

Modified:
cfe/branches/release_60/docs/ReleaseNotes.rst

Modified: cfe/branches/release_60/docs/ReleaseNotes.rst
URL:


http://llvm.org/viewvc/llvm-project/cfe/branches/release_60/docs/ReleaseNotes.rst?rev=323179&r1=323178&r2=323179&view=diff

[3]


==

--- cfe/branches/release_60/docs/ReleaseNotes.rst (original)
+++ cfe/branches/release_60/docs/ReleaseNotes.rst Mon Jan 22
23:50:11 2018
@@ -231,6 +231,13 @@ OpenMP Support in Clang
- Added support for `reduction`-based clauses on `task`-based
directives from
upcoming OpenMP 5.0.

+- The LLVM OpenMP runtime `libomp` now supports the OpenMP Tools
Interface (OMPT)
+  on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS.
If you observe
+  a measurable performance impact on one of your applications
without a tool
+  attached, please rebuild the runtime library with
`-DLIBOMP_OMPT_SUPPORT=OFF` and
+  file a bug at `LLVM's Bugzilla `_ or send
a message to the
+  `OpenMP development list
`_.
+
Internal API Changes


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[5]




Links:
--
[1] http://llvm.org/viewvc/llvm-project?rev=323179&view=rev
[2] https://reviews.llvm.org/D42352
[3]
http://llvm.org/viewvc/llvm-project/cfe/branches/release_60/docs/ReleaseNotes.rst?rev=323179&r1=323178&r2=323179&view=diff
[4] http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
[5] http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

Re: [llvm-branch-commits] [cfe-branch] r323179 - [ReleaseNotes] Mention OpenMP Tools Interface in runtime library

[Hans Wennborg via llvm-branch-commits]

Is there a buildbot that tests it regularly on Windows, ideally built with
Clang?

I'm sorry that I seem grumpy about this, but there appears to be a problem
here.

On Thu, Feb 1, 2018 at 10:30 AM, Jonas Hahnfeld  wrote:

> I think it actually works _if_ you get Clang to link to the right runtime
> library... Adding Joachim and Olga who have been working on this lately.
>
> Am 2018-02-01 10:26, schrieb Hans Wennborg:
>
>> As far as I understand, this doesn't actually work on Windows. Should
>> we update the text?
>>
>> On Tue, Jan 23, 2018 at 8:50 AM, Jonas Hahnfeld via
>> llvm-branch-commits  wrote:
>>
>> Author: hahnfeld
>>> Date: Mon Jan 22 23:50:11 2018
>>> New Revision: 323179
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=323179&view=rev [1]
>>> Log:
>>> [ReleaseNotes] Mention OpenMP Tools Interface in runtime library
>>>
>>> The OpenMP runtime has no dedicated Release Notes, so add it to
>>> Clang's
>>> section about OpenMP.
>>>
>>> Differential Revision: https://reviews.llvm.org/D42352 [2]
>>>
>>> Modified:
>>> cfe/branches/release_60/docs/ReleaseNotes.rst
>>>
>>> Modified: cfe/branches/release_60/docs/ReleaseNotes.rst
>>> URL:
>>>
>>> http://llvm.org/viewvc/llvm-project/cfe/branches/release_60/
>> docs/ReleaseNotes.rst?rev=323179&r1=323178&r2=323179&view=diff
>>
>>> [3]
>>>
>>> 
>> ==
>>
>>> --- cfe/branches/release_60/docs/ReleaseNotes.rst (original)
>>> +++ cfe/branches/release_60/docs/ReleaseNotes.rst Mon Jan 22
>>> 23:50:11 2018
>>> @@ -231,6 +231,13 @@ OpenMP Support in Clang
>>> - Added support for `reduction`-based clauses on `task`-based
>>> directives from
>>> upcoming OpenMP 5.0.
>>>
>>> +- The LLVM OpenMP runtime `libomp` now supports the OpenMP Tools
>>> Interface (OMPT)
>>> +  on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS.
>>> If you observe
>>> +  a measurable performance impact on one of your applications
>>> without a tool
>>> +  attached, please rebuild the runtime library with
>>> `-DLIBOMP_OMPT_SUPPORT=OFF` and
>>> +  file a bug at `LLVM's Bugzilla `_ or send
>>> a message to the
>>> +  `OpenMP development list
>>> `_.
>>> +
>>> Internal API Changes
>>> 
>>>
>>> ___
>>> llvm-branch-commits mailing list
>>> llvm-branch-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
>>> [5]
>>>
>>
>>
>>
>> Links:
>> --
>> [1] http://llvm.org/viewvc/llvm-project?rev=323179&view=rev
>> [2] https://reviews.llvm.org/D42352
>> [3]
>> http://llvm.org/viewvc/llvm-project/cfe/branches/release_60/
>> docs/ReleaseNotes.rst?rev=323179&r1=323178&r2=323179
>> &view=diff
>> [4] http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>> [5] http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
>>
>
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

Re: [llvm-branch-commits] [cfe-branch] r323179 - [ReleaseNotes] Mention OpenMP Tools Interface in runtime library

[Jonas Hahnfeld via llvm-branch-commits]

No, there isn't and I fully agree that this is far from ideal. However, 
we are only running an x86 Linux cluster and that's where I try to get 
coverage for.


From my part, feel free to remove the part about Windows if you think 
it's better for user experience. I've never used OpenMP on Windows and 
certainly won't look into issues there.


Thanks,
Jonas

Am 2018-02-01 10:38, schrieb Hans Wennborg:

Is there a buildbot that tests it regularly on Windows, ideally built
with Clang?

I'm sorry that I seem grumpy about this, but there appears to be a
problem here.

On Thu, Feb 1, 2018 at 10:30 AM, Jonas Hahnfeld 
wrote:


I think it actually works _if_ you get Clang to link to the right
runtime library... Adding Joachim and Olga who have been working on
this lately.

Am 2018-02-01 10:26, schrieb Hans Wennborg:
As far as I understand, this doesn't actually work on Windows.
Should
we update the text?

On Tue, Jan 23, 2018 at 8:50 AM, Jonas Hahnfeld via
llvm-branch-commits  wrote:

Author: hahnfeld
Date: Mon Jan 22 23:50:11 2018
New Revision: 323179

URL: http://llvm.org/viewvc/llvm-project?rev=323179&view=rev [1]
[1]
Log:
[ReleaseNotes] Mention OpenMP Tools Interface in runtime library

The OpenMP runtime has no dedicated Release Notes, so add it to
Clang's
section about OpenMP.

Differential Revision: https://reviews.llvm.org/D42352 [2] [2]

Modified:
cfe/branches/release_60/docs/ReleaseNotes.rst

Modified: cfe/branches/release_60/docs/ReleaseNotes.rst
URL:



http://llvm.org/viewvc/llvm-project/cfe/branches/release_60/docs/ReleaseNotes.rst?rev=323179&r1=323178&r2=323179&view=diff

[3]
[3]



==

--- cfe/branches/release_60/docs/ReleaseNotes.rst (original)
+++ cfe/branches/release_60/docs/ReleaseNotes.rst Mon Jan 22
23:50:11 2018
@@ -231,6 +231,13 @@ OpenMP Support in Clang
- Added support for `reduction`-based clauses on `task`-based
directives from
upcoming OpenMP 5.0.

+- The LLVM OpenMP runtime `libomp` now supports the OpenMP Tools
Interface (OMPT)
+  on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS.
If you observe
+  a measurable performance impact on one of your applications
without a tool
+  attached, please rebuild the runtime library with
`-DLIBOMP_OMPT_SUPPORT=OFF` and
+  file a bug at `LLVM's Bugzilla `_ or send
a message to the
+  `OpenMP development list
`_.
+
Internal API Changes


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-branch] r324007 - Merging r323155:

[Reid Kleckner via llvm-branch-commits]

Author: rnk
Date: Thu Feb  1 13:28:26 2018
New Revision: 324007

URL: http://llvm.org/viewvc/llvm-project?rev=324007&view=rev
Log:
Merging r323155:

r323155 | chandlerc | 2018-01-22 14:05:25 -0800 (Mon, 22 Jan 2018) | 133 lines

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 sh

[llvm-branch-commits] [llvm-branch] r324009 - Merging r323915:

[Reid Kleckner via llvm-branch-commits]

Author: rnk
Date: Thu Feb  1 13:31:35 2018
New Revision: 324009

URL: http://llvm.org/viewvc/llvm-project?rev=324009&view=rev
Log:
Merging r323915:

r323915 | chandlerc | 2018-01-31 12:56:37 -0800 (Wed, 31 Jan 2018) | 17 lines

[x86] Make the retpoline thunk insertion a machine function pass.

Summary:
This removes the need for a machine module pass using some deeply
questionable hacks. This should address PR36123 which is a case where in
full LTO the memory usage of a machine module pass actually ended up
being significant.

We should revert this on trunk as soon as we understand and fix the
memory usage issue, but we should include this in any backports of
retpolines themselves.

Reviewers: echristo, MatzeB

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

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


Modified:
llvm/branches/release_50/   (props changed)
llvm/branches/release_50/lib/Target/X86/X86.h
llvm/branches/release_50/lib/Target/X86/X86RetpolineThunks.cpp
llvm/branches/release_50/test/CodeGen/X86/O0-pipeline.ll

Propchange: llvm/branches/release_50/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Thu Feb  1 13:31:35 2018
@@ -1,2 +1,2 @@
-/llvm/trunk:313366,323155
+/llvm/trunk:313366,323155,323915
 
/llvm/trunk:155241,308483-308484,308503,308808,308813,308847,308891,308906,308950,308963,308978,308986,309044,309071,309113,309120,309122,309140,309227,309302,309321,309323,309325,309330,309343,309353,309355,309422,309481,309483,309495,309555,309561,309594,309614,309651,309744,309758,309849,309928,309930,309945,310066,310071,310190,310240-310242,310250,310253,310262,310267,310481,310492,310498,310510,310534,310552,310604,310712,310779,310784,310796,310842,310906,310926,310939,310979,310988,310990-310991,311061,311068,311071,311087,311229,311258,311263,311387,311429,311554,311565,311572,311623,311835,312022,312285,313334:312337

Modified: llvm/branches/release_50/lib/Target/X86/X86.h
URL: 
http://llvm.org/viewvc/llvm-project/llvm/branches/release_50/lib/Target/X86/X86.h?rev=324009&r1=324008&r2=324009&view=diff
==
--- llvm/branches/release_50/lib/Target/X86/X86.h (original)
+++ llvm/branches/release_50/lib/Target/X86/X86.h Thu Feb  1 13:31:35 2018
@@ -100,7 +100,7 @@ void initializeFixupBWInstPassPass(PassR
 FunctionPass *createX86EvexToVexInsts();
 
 /// This pass creates the thunks for the retpoline feature.
-ModulePass *createX86RetpolineThunksPass();
+FunctionPass *createX86RetpolineThunksPass();
 
 InstructionSelector *createX86InstructionSelector(const X86TargetMachine &TM,
   X86Subtarget &,

Modified: llvm/branches/release_50/lib/Target/X86/X86RetpolineThunks.cpp
URL: 
http://llvm.org/viewvc/llvm-project/llvm/branches/release_50/lib/Target/X86/X86RetpolineThunks.cpp?rev=324009&r1=324008&r2=324009&view=diff
==
--- llvm/branches/release_50/lib/Target/X86/X86RetpolineThunks.cpp (original)
+++ llvm/branches/release_50/lib/Target/X86/X86RetpolineThunks.cpp Thu Feb  1 
13:31:35 2018
@@ -38,18 +38,27 @@ using namespace llvm;
 
 #define DEBUG_TYPE "x86-retpoline-thunks"
 
+static const char ThunkNamePrefix[] = "__llvm_retpoline_";
+static const char R11ThunkName[]= "__llvm_retpoline_r11";
+static const char EAXThunkName[]= "__llvm_retpoline_eax";
+static const char ECXThunkName[]= "__llvm_retpoline_ecx";
+static const char EDXThunkName[]= "__llvm_retpoline_edx";
+static const char PushThunkName[]   = "__llvm_retpoline_push";
+
 namespace {
-class X86RetpolineThunks : public ModulePass {
+class X86RetpolineThunks : public MachineFunctionPass {
 public:
   static char ID;
 
-  X86RetpolineThunks() : ModulePass(ID) {}
+  X86RetpolineThunks() : MachineFunctionPass(ID) {}
 
   StringRef getPassName() const override { return "X86 Retpoline Thunks"; }
 
-  bool runOnModule(Module &M) override;
+  bool doInitialization(Module &M) override;
+  bool runOnMachineFunction(MachineFunction &F) override;
 
   void getAnalysisUsage(AnalysisUsage &AU) const override {
+MachineFunctionPass::getAnalysisUsage(AU);
 AU.addRequired();
 AU.addPreserved();
   }
@@ -61,51 +70,74 @@ private:
   const X86Subtarget *STI;
   const X86InstrInfo *TII;
 
-  Function *createThunkFunction(Module &M, StringRef Name);
+  bool InsertedThunks;
+
+  void createThunkFunction(Module &M, StringRef Name);
   void insertRegReturnAddrClobber(MachineBasicBlock &MBB, unsigned Reg);
   void insert32BitPushReturnAddrClobber(MachineBasicBlock &MBB);
-  void createThunk(Module &M, StringRef NameSuffix,
-   Optional Reg = None);
+  void populateThunk(Mac

[llvm-branch-commits] [cfe-branch] r324012 - Merging r323155:

[Reid Kleckner via llvm-branch-commits]

Author: rnk
Date: Thu Feb  1 13:46:03 2018
New Revision: 324012

URL: http://llvm.org/viewvc/llvm-project?rev=324012&view=rev
Log:
Merging r323155:

r323155 | chandlerc | 2018-01-22 14:05:25 -0800 (Mon, 22 Jan 2018) | 133 lines

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 sh

[llvm-branch-commits] [lld] r324025 - Merging r323155 in LLD, with modifications to handle int3 fill

[Reid Kleckner via llvm-branch-commits]

Author: rnk
Date: Thu Feb  1 14:37:22 2018
New Revision: 324025

URL: http://llvm.org/viewvc/llvm-project?rev=324025&view=rev
Log:
Merging r323155 in LLD, with modifications to handle int3 fill

Original commit message:

r323155 | chandlerc | 2018-01-22 14:05:25 -0800 (Mon, 22 Jan 2018) | 133 lines

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 wi

[llvm-branch-commits] [lld] r324026 - Merging r323288:

[Reid Kleckner via llvm-branch-commits]

Author: rnk
Date: Thu Feb  1 14:39:52 2018
New Revision: 324026

URL: http://llvm.org/viewvc/llvm-project?rev=324026&view=rev
Log:
Merging r323288:

r323288 | ruiu | 2018-01-23 16:26:57 -0800 (Tue, 23 Jan 2018) | 3 lines

Fix retpoline PLT header size for i386.

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


Modified:
lld/branches/release_50/   (props changed)
lld/branches/release_50/ELF/Arch/X86.cpp
lld/branches/release_50/test/ELF/i386-retpoline-nopic.s

Propchange: lld/branches/release_50/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Thu Feb  1 14:39:52 2018
@@ -1 +1 @@
-/lld/trunk:308492,308728,308935,308998,309002,310526,310989,310992,312706,313741,323155
+/lld/trunk:308492,308728,308935,308998,309002,310526,310989,310992,312706,313741,323155,323288

Modified: lld/branches/release_50/ELF/Arch/X86.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lld/branches/release_50/ELF/Arch/X86.cpp?rev=324026&r1=324025&r2=324026&view=diff
==
--- lld/branches/release_50/ELF/Arch/X86.cpp (original)
+++ lld/branches/release_50/ELF/Arch/X86.cpp Thu Feb  1 14:39:52 2018
@@ -438,7 +438,7 @@ void RetpolinePic::writePlt(uint8_t *Buf
 }
 
 RetpolineNoPic::RetpolineNoPic() {
-  PltHeaderSize = 64;
+  PltHeaderSize = 48;
   PltEntrySize = 32;
 }
 
@@ -464,10 +464,6 @@ void RetpolineNoPic::writePltHeader(uint
   0x59,// 2d:   pop %ecx
   0xc3,// 2e:   ret
   0xcc,// 2f:   int3
-  0xcc, 0xcc, 0xcc, 0xcc,
-  0xcc, 0xcc, 0xcc, 0xcc, 
-  0xcc, 0xcc, 0xcc, 0xcc, 
-  0xcc, 0xcc, 0xcc, 0xcc, 
   };
   memcpy(Buf, PltData, sizeof(PltData));
   assert(sizeof(PltData) == TargetInfo::PltHeaderSize);

Modified: lld/branches/release_50/test/ELF/i386-retpoline-nopic.s
URL: 
http://llvm.org/viewvc/llvm-project/lld/branches/release_50/test/ELF/i386-retpoline-nopic.s?rev=324026&r1=324025&r2=324026&view=diff
==
--- lld/branches/release_50/test/ELF/i386-retpoline-nopic.s (original)
+++ lld/branches/release_50/test/ELF/i386-retpoline-nopic.s Thu Feb  1 14:39:52 
2018
@@ -30,50 +30,34 @@
 // CHECK-NEXT: 1103d:   59  popl%ecx
 // CHECK-NEXT: 1103e:   c3  retl
 // CHECK-NEXT: 1103f:   cc  int3
-// CHECK-NEXT: 11040:   cc  int3
-// CHECK-NEXT: 11041:   cc  int3
-// CHECK-NEXT: 11042:   cc  int3
-// CHECK-NEXT: 11043:   cc  int3
-// CHECK-NEXT: 11044:   cc  int3
-// CHECK-NEXT: 11045:   cc  int3
-// CHECK-NEXT: 11046:   cc  int3
-// CHECK-NEXT: 11047:   cc  int3
-// CHECK-NEXT: 11048:   cc  int3
-// CHECK-NEXT: 11049:   cc  int3
-// CHECK-NEXT: 1104a:   cc  int3
-// CHECK-NEXT: 1104b:   cc  int3
-// CHECK-NEXT: 1104c:   cc  int3
-// CHECK-NEXT: 1104d:   cc  int3
-// CHECK-NEXT: 1104e:   cc  int3
-// CHECK-NEXT: 1104f:   cc  int3
-// CHECK-NEXT: 11050:   50  pushl   %eax
-// CHECK-NEXT: 11051:   a1 0c 20 01 00  movl73740, %eax
-// CHECK-NEXT: 11056:   e8 d5 ff ff ff  calll   -43 <.plt+0x20>
-// CHECK-NEXT: 1105b:   e9 c1 ff ff ff  jmp -63 <.plt+0x11>
-// CHECK-NEXT: 11060:   68 00 00 00 00  pushl   $0
-// CHECK-NEXT: 11065:   e9 a6 ff ff ff  jmp -90 <.plt>
-// CHECK-NEXT: 1106a:   cc  int3
-// CHECK-NEXT: 1106b:   cc  int3
-// CHECK-NEXT: 1106c:   cc  int3
-// CHECK-NEXT: 1106d:   cc  int3
-// CHECK-NEXT: 1106e:   cc  int3
-// CHECK-NEXT: 1106f:   cc  int3
-// CHECK-NEXT: 11070:   50  pushl   %eax
-// CHECK-NEXT: 11071:   a1 10 20 01 00  movl73744, %eax
-// CHECK-NEXT: 11076:   e8 b5 ff ff ff  calll   -75 <.plt+0x20>
-// CHECK-NEXT: 1107b:   e9 a1 ff ff ff  jmp -95 <.plt+0x11>
-// CHECK-NEXT: 11080:   68 08 00 00 00  pushl   $8
-// CHECK-NEXT: 11085:   e9 86 ff ff ff  jmp -122 <.plt>
-// CHECK-NEXT: 1108a:   cc  int3
-// CHECK-NEXT: 1108b:   cc  int3
-// CHECK-NEXT: 1108c:   cc  int3
-// CHECK-NEXT: 1108d:   cc  int3
-// CHECK-NEXT: 1108e:   cc  int3
-// CHECK-NEXT: 1108f:   cc  int3
+// CHECK-NEXT: 11040:   50  pushl   %eax
+// CHECK-NEXT: 11041:   a1 0c 20 01 00  movl73740, %eax
+// CHECK-NEXT: 11046:   e8 e5 ff ff ff  calll   -27 <.plt+0x20>
+// CHECK-NEXT: 1104b:   e9 d1 ff ff ff  jmp -47 <.plt+0x11>
+// CHECK-NEXT: 11050:   68 00 00 00 00  pushl   $0
+// CHECK-NEXT: 11055:   e9 b6 ff ff ff  jmp -74 <.plt>
+// CHECK-NEXT: 1105a:   cc  int3
+// CHECK-NEXT: 1105b:   cc  i