search for: retpolines

...line) and whole-program devirtualization (-fwhole-program-vtables) features are enabled (the former is on the assumption that in general a regular indirect call will be less expensive than a branch funnel, and the latter provides the necessary guarantee that the type hierarchy is closed). Even when retpolines are enabled, there is still a cost associated with executing a branch funnel that needs to be balanced against the cost of a regular CFI check and retpoline, so branch funnels are only used when there are <=10 targets (this number has not been tuned yet). Because the implementation uses some of...

...ram devirtualization > (-fwhole-program-vtables) features are enabled (the former is on the > assumption that in general a regular indirect call will be less expensive > than a branch funnel, and the latter provides the necessary guarantee that > the type hierarchy is closed). Even when retpolines are enabled, there is > still a cost associated with executing a branch funnel that needs to be > balanced against the cost of a regular CFI check and retpoline, so branch > funnels are only used when there are <=10 targets (this number has not been > tuned yet). Because the implemen...

...(-fwhole-program-vtables) features are enabled (the former is on the > assumption that in general a regular indirect call will be less > expensive than a branch funnel, and the latter provides the > necessary guarantee that the type hierarchy is closed). Even when > retpolines are enabled, there is still a cost associated with > executing a branch funnel that needs to be balanced against the cost > of a regular CFI check and retpoline, so branch funnels are only > used when there are <=10 targets (this number has not been tuned > yet). Beca...

On Wed, 2018-02-07 at 00:36 +0000, Chandler Carruth wrote: > > > > That would be __x86_indirect_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

On Tue, Feb 6, 2018 at 4:46 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Wed, 2018-02-07 at 00:36 +0000, Chandler Carruth wrote: > > > > > > > That would be __x86_indirect_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

...stribution 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 -fno-plt, so you need a special linker that produces non-standard PLT stubs. (And this has to be repeated for all system libraries you call.) In our case, it caused miscompilation because it triggered two different GCC bugs (which are being fixed upstream): <https:...

Also, could 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

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:

The patch is up for review here: https://reviews.llvm.org/D42998 On Tue, Feb 6, 2018 at 4:58 PM Chandler Carruth <chandlerc at google.com> wrote: > Also, could 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 >

On Fri, 2018-02-09 at 08:45 +0000, Chandler Carruth wrote: > > > > You're pushing the target (-0x20(%ebp)) onto the stack and then > > *calling* __x86_indirect_thunk. So it looks like you're expecting > > __x86_indirect_thunk to do something like > > > >   call *4(%esp) > >   ret > > > > ... except that final 'ret' still

On Fri, Feb 9, 2018 at 12:26 AM David Woodhouse <dwmw2 at infradead.org> wrote: > > > 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

.... That sounds good to me; thanks. > One question I have: how important is this? Specifically, does the > attribute need to get backported? No, we can live without it. It's a slight performance optimisation, that none of the init code in the kernel itself actually has to be built with retpolines. But it isn't imperative. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180208/b261459d/attachment.bin>

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

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

...s. > > > One question I have: how important is this? Specifically, does the > > attribute need to get backported? > > No, we can live without it. It's a slight performance optimisation, > that none of the init code in the kernel itself actually has to be > built with retpolines. But it isn't imperative. > Makes sense, I'll do this as part of the requested cleanup to how we model whether or not to do retpolines. Thanks, -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachm...

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

On Wed, 2018-02-07 at 10:11 -0800, Guenter Roeck wrote: > On Wed, Feb 07, 2018 at 10:49:25AM +0000, David Woodhouse wrote: > > Hm, please could we also have the %V asm constraint modifier? That > > allows us to emit calls to the thunks from inline asm using the > > register that the compiler chose for us: > > > >  asm volatile ("call

Hi all! I'm running an up-to-date Centos-7 on an AMD Vishera 6300, 6 core CPU. I note that when I run the redhat script to test for spectre & meltdown I get this result for variant 2: Variant #2 (Spectre): Vulnerable CVE-2017-5715 - speculative execution branch target injection - Kernel with mitigation patches: OK - HW support / updated microcode: NO - IBRS: Not disabled on

Jan Kara <jack at suse.cz> writes: > On Thu 11-04-19 07:51:48, Dan Williams wrote: >> On Tue, Apr 9, 2019 at 9:09 PM Pankaj Gupta <pagupta at redhat.com> wrote: >> > + } else { >> > + if (nd_region->flush(nd_region)) >> > + rc = -EIO; >> >> Given the common case wants to be fast and

Jan Kara <jack at suse.cz> writes: > On Thu 11-04-19 07:51:48, Dan Williams wrote: >> On Tue, Apr 9, 2019 at 9:09 PM Pankaj Gupta <pagupta at redhat.com> wrote: >> > + } else { >> > + if (nd_region->flush(nd_region)) >> > + rc = -EIO; >> >> Given the common case wants to be fast and