search for: retpoline

The proposed mitigation for variant 2 of CVE-2017-5715, “branch target injection”, is to send all indirect branches through an instruction sequence known as a retpoline. Because the purpose of a retpoline is to prevent attacker-controlled speculation, we also end up losing the benefits of benign speculation, which can lead to a measurable loss of performance. We can regain some of those benefits if we know that the set of possible branch targets is fixed (this is...

...-- Sean Silva On Tue, Jan 23, 2018 at 4:44 PM, Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The proposed mitigation for variant 2 of CVE-2017-5715, “branch target > injection”, is to send all indirect branches through an instruction > sequence known as a retpoline. Because the purpose of a retpoline is to > prevent attacker-controlled speculation, we also end up losing the benefits > of benign speculation, which can lead to a measurable loss of performance. > > We can regain some of those benefits if we know that the set of possible > branch t...

...urne via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > The proposed mitigation for variant 2 of CVE-2017-5715, “branch > target injection”, is to send all indirect branches through an > instruction sequence known as a retpoline. Because the purpose of a > retpoline is to prevent attacker-controlled speculation, we also end > up losing the benefits of benign speculation, which can lead to a > measurable loss of performance. > > We can regain some of those benefits if we know that the set of...

...thunk but the kernel doesn't use it. > > We use -mindirect-branch-register and only ever expect the compiler > > to use the register versions which are CET-compatible. > > > > However, in at least one case in the 32-bit kernel we do emit the > > old ret-equivalent retpoline inline, because there literally wasn't > > a single register we could use (yay x86). > > > > I would definitely consider ditching our use of -mindirect-thunk- > > register with GCC for 32-bit and exporting the > > __x86_indirect_thunk, to be consistent if that'...

...sn't use it. > > > We use -mindirect-branch-register and only ever expect the compiler > > > to use the register versions which are CET-compatible. > > > > > > However, in at least one case in the 32-bit kernel we do emit the > > > old ret-equivalent retpoline inline, because there literally wasn't > > > a single register we could use (yay x86). > > > > > > I would definitely consider ditching our use of -mindirect-thunk- > > > register with GCC for 32-bit and exporting the > > > __x86_indirect_thunk, to b...

We recently discovered that our OpenSSH distribution binaries contain retpoline thunks. It's due to this OSSH_CHECK_CFLAG_COMPILE([-mfunction-return=thunk]) # gcc OSSH_CHECK_CFLAG_COMPILE([-mindirect-branch=thunk]) # gcc This was quite surprising because at least the GNU/Linux userspace has no provisions for retpolines. You also fail to enable...

...you patch and test Clang with the Linux kernel after I make this change? I'd like to know that we actually successfully call the correct thunks and that they behave correctly. I'm not super worried, but good to actually get this right. I'm am slightly more worried about the stack-based retpoline than the register ones just due to the overall lower amount of testing we've had there. On Tue, Feb 6, 2018 at 4:56 PM Chandler Carruth <chandlerc at google.com> wrote: > On Tue, Feb 6, 2018 at 4:46 PM David Woodhouse <dwmw2 at infradead.org> > wrote: > >> On Wed, 2...

Hi all, I saw the retpoline mitigation landed in r323155. Are we ready to merge this to 6.0, or are there any open issues that we're waiting for? Also, were there any followups I should know about? Also, release notes please :-) Thanks, Hans -------------- next part -------------- An HTML attachment was scrubbed... URL:...

...lang with the Linux kernel after I make > this change? I'd like to know that we actually successfully call the > correct thunks and that they behave correctly. I'm not super worried, but > good to actually get this right. I'm am slightly more worried about the > stack-based retpoline than the register ones just due to the overall lower > amount of testing we've had there. > > On Tue, Feb 6, 2018 at 4:56 PM Chandler Carruth <chandlerc at google.com> > wrote: > >> On Tue, Feb 6, 2018 at 4:46 PM David Woodhouse <dwmw2 at infradead.org> >>...

...to pop that too. > > Yeah, we expect a complicated dance to re-order the stack to get the > correct return address into the correct place. > > You can see the sequence in the comments here: > https://github.com/llvm-project/llvm-project-20170507/blob/master/llvm/lib/Target/X86/X86RetpolineThunks.cpp#L179-L194 Great, thanks. > Anyways, it appears that we have the first case where my suspicions > were borne out and we have somewhat reasonably different ABIs for > some of the thunks. > > How should we name them to distinguish things?  For now it's only ever going...

...> On Fri, 2018-02-09 at 02:21 +0000, David Woodhouse wrote: > > On Fri, 2018-02-09 at 01:18 +0000, David Woodhouse wrote: > > > > > > > > > For now I'm just going to attempt to work around it like this in the > > > kernel, so I can concentrate on the retpoline bits: > > > http://david.woodhou.se/clang-percpu-hack.patch > > > > 32-bit doesn't boot. Built without CONFIG_RETPOLINE and with Clang 5.0 > > (and the above patch) it does. I'm rebuilding a Release build of > > llvm/clang so that experimental kernel builds...

...3:48 +0000, Chandler Carruth wrote: > Bringing everything back to this thread -- we now have %V support > landed in top-of-tree, so wanted to get confirmation that top-of-tree > is healthy for the kernel, or see what else we need to do. For 64-bit it's fine. For 32-bit we *think* the retpoline bits are OK but it doesn't build for other reasons on 32-bit. But that isn't new breakage — 5.0 has the same problem with the latest kernel. I'll see if we can work around that in the kernel, instead of relying on certain inline asms getting optimised away before the compiler ever notic...

On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote: > > I saw the retpoline mitigation landed in r323155. Are we ready to > merge this to 6.0, or are there any open issues that we're waiting > for? Also, were there any followups I should know about? Also, > release notes please :-) Eep, please can we keep the command line option for clang and the thunk ABI ma...

On Fri, 2018-02-09 at 01:18 +0000, David Woodhouse wrote: > > For now I'm just going to attempt to work around it like this in the > kernel, so I can concentrate on the retpoline bits: >  http://david.woodhou.se/clang-percpu-hack.patch 32-bit doesn't boot. Built without CONFIG_RETPOLINE and with Clang 5.0 (and the above patch) it does. I'm rebuilding a Release build of llvm/clang so that experimental kernel builds hopefully take less than an hour, and will prod...

...rruth wrote: > > Bringing everything back to this thread -- we now have %V support > > landed in top-of-tree, so wanted to get confirmation that top-of-tree > > is healthy for the kernel, or see what else we need to do. > > For 64-bit it's fine. For 32-bit we *think* the retpoline bits are OK > but it doesn't build for other reasons on 32-bit. But that isn't new > breakage — 5.0 has the same problem with the latest kernel. I'll see if > we can work around that in the kernel, instead of relying on certain > inline asms getting optimised away before the...

On Fri, 2018-02-09 at 02:21 +0000, David Woodhouse wrote: > On Fri, 2018-02-09 at 01:18 +0000, David Woodhouse wrote: > > > > > > For now I'm just going to attempt to work around it like this in the > > kernel, so I can concentrate on the retpoline bits: > >  http://david.woodhou.se/clang-percpu-hack.patch > > 32-bit doesn't boot. Built without CONFIG_RETPOLINE and with Clang 5.0 > (and the above patch) it does. I'm rebuilding a Release build of > llvm/clang so that experimental kernel builds hopefully take less than...

... asm volatile ("call __x86_indirect_thunk_%V[thunk_target]" : : > > [thunk_target] "r" (the_function));  > > > > Other than that, I get the following errors with LLVM+Clang master, and > > my tree at > > http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb > > > I tried ToT clang with Linux upstream as well as chromeos-4.14, > with 'defconfig'. I don't see any errors when building x86_64. > Lots and lots of warnings, though. The defconfig doesn't build here either; it still includes the cp...

...ace: NO (kernel confirms your system is vulnerable) * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: YES * Currently enabled features * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * IBPB enabled: NO * Mitigation 2 * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: UNKNOWN > STATUS: VULNERABLE (Vulnerable: Retpoline without IBPB) So, I"m wondering: 1. has RH in fact released mitigations for this issue for AMD processors, and 2. has AMD released microcode updates for this? I have...

...ta <pagupta at redhat.com> wrote: >> > + } else { >> > + if (nd_region->flush(nd_region)) >> > + rc = -EIO; >> >> Given the common case wants to be fast and synchronous I think we >> should try to avoid retpoline overhead by default. So something like >> this: >> >> if (nd_region->flush == generic_nvdimm_flush) >> rc = generic_nvdimm_flush(...); > > I'd either add a comment about avoiding retpoline overhead here or just > make ->flush == NULL mean generic_nvdi...

...ta <pagupta at redhat.com> wrote: >> > + } else { >> > + if (nd_region->flush(nd_region)) >> > + rc = -EIO; >> >> Given the common case wants to be fast and synchronous I think we >> should try to avoid retpoline overhead by default. So something like >> this: >> >> if (nd_region->flush == generic_nvdimm_flush) >> rc = generic_nvdimm_flush(...); > > I'd either add a comment about avoiding retpoline overhead here or just > make ->flush == NULL mean generic_nvdi...