similar to: FYI, we've posted a component of Spectre mitigation on llvm-commits

Thanks for the notification, Chandler. I also wanted to note that I’ve just posted another component for Spectre mitigation (variant 1), see https://reviews.llvm.org/D41760 and https://reviews.llvm.org/D41761. I believe this is completely complementary to the retpoline mitigation you pointed to at https://reviews.llvm.org/D41723#, which is targeted at mitigating variant 2. Thanks, Kristof On 4

Awesome, replied. We've been working on similar things, but didn't have them ready-to-publish due to slightly lower urgency (there are reasonable ways to locally mimic these kinds of things in sensitive areas like the Linux kernel, and even finding code patterns for variant #1 is substantially harder). We have some significantly different APIs we'd like to discuss here based on

On 4 January 2018 at 10:23, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sending a note here as this seems likely to be of relatively broad interest. > > Thread: > http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html > > Review link: > https://reviews.llvm.org/D41723# It seems the review link is getting wider coverage

On Thu, Jan 4, 2018 at 12:31 PM Stephen Checkoway via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Jan 4, 2018, at 04:23, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Sending a note here as this seems likely to be of relatively broad > interest. > > It looks like this is producing code of the following form.

On Jan 4, 2018, at 11:52, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Thu, Jan 4, 2018 at 12:31 PM Stephen Checkoway via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> As I understand it, the busy loop is to cause the speculative execution to be trapped in the loop. Was something like ud2 considered? I presume that would stop the speculative

The folks working on phab are busily propping it up. It should be relatively healthy now. On Thu, Jan 4, 2018 at 9:20 AM Alex Bradbury via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 4 January 2018 at 10:23, Chandler Carruth via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Sending a note here as this seems likely to be of relatively broad > interest. >

> On Jan 4, 2018, at 04:23, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Sending a note here as this seems likely to be of relatively broad interest. It looks like this is producing code of the following form. call next loop: pause jmp loop next: mov [rsp], r11 ret As I understand it, the busy loop is to cause the speculative execution to be trapped

On 4 January 2018 at 16:49, Chandler Carruth <chandlerc at gmail.com> wrote: > The folks working on phab are busily propping it up. It should be relatively > healthy now. Many thanks to those good people! Have you considered developing the patch description into a blog post for blog.llvm.org, maybe after the patch lands? Best, Alex

Hi LLVM developers, Does it need to implement <Target>RetpolineThunksPass, `getOpcodeForRetpoline`, `EmitLoweredRetpoline`, etc. for other Targets? Or does it also need to implement `RetpolinePic` to inherit from <Target> for LLD's Backends? Alex is my mentor, he is leading me to maintain RISCV target, so I have such question, please give me suggestions, thanks for your

On Fri, Jan 5, 2018 at 12:51 AM Leslie Zhai via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi LLVM developers, > > Does it need to implement <Target>RetpolineThunksPass, > `getOpcodeForRetpoline`, `EmitLoweredRetpoline`, etc. for other Targets? > Or does it also need to implement `RetpolinePic` to inherit from > <Target> for LLD's Backends? Alex is my

FYI to all: I've updated the design document to include the newly disclosed variants 1.1 and 1.2 (collectively called Bounds Check Bypass Store or BCBS). There is no change to the proposed implementation which can already robustly mitigate these variants. I've also updated my patch as we have very significant interest in getting at least an early "beta" version of this into the

Hi all, I understand how the speculative information flow attack works. I'm trying get my head around the spectre v1 mitigation of LLVM. In the design document here : https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening. <https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening> Example: void leak(int data);void example(int* pointer1,

Hi Chandler, Thank you very much for sharing this! The RFC is pretty lengthy but the far majority of it makes sense to me. I’m sure I’m forgetting to react to some aspects below, but I thought I’d summarize some initial thoughts and questions I had after reading the RFC end-to-end. * I believe the same high-level principles you outline can also be used to implement the same protection on the

Hi, Thanks for your email, I understand that the execution stalls until the predicated state is computed, then we mask pointers with all_zeros_mask if there is a mis-prediction. But I understand that as soon as the condition value is available, the processor can check about it's assumptions and revert back. That is, If the branch prediction is correct during speculation, we mask with

Hi, Yeah, now I understand the problem here. Thanks. But I too have another doubt in "Bounds check bypass store" In this example in the Speculative load hardening : unsigned char local_buffer[4];unsigned char *untrusted_data_from_caller = ...;unsigned long untrusted_size_from_caller = ...;if (untrusted_size_from_caller < sizeof(local_buffer)) { // Speculative execution enters here

On 6 February 2018 at 20:09, David Newall <openssh at davidnewall.com> wrote: > Do we need to do anything? It's not clear to me how SSH is vulnerable to > Spectre -- that is, how SSH can be used to execute a Spectre attack? I am more concerned with it being the target of a Spectre style attack. There's some long lived private data (host keys in the case of sshd, session keys

Hi. Both GCC and clang are adding mitigations for Spectre variant 2 although neither have yet made a release and neither are on by default. After trolling through and building release candidate branches for both I believe this is what is required for the ssh programs (although all the dependent libraries will also need to be built with mitigations, and I suspect libcrypto is a more likely

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

Hello all, I've been working for the last month or so on a comprehensive mitigation approach to variant #1 of Spectre. There are a bunch of reasons why this is desirable: - Critical software that is unlikely to be easily hand-mitigated (or where the performance tradeoff isn't worth it) will have a compelling option. - It gives us a baseline on performance for hand-mitigation. - Combined

On 16/03/18 18:24, Fred Smith wrote: > Hi all! > > I'm running an up-to-date Centos-7 on an AMD Vishera 6300, 6 core CPU. > What kernel are you running (uname -r)? > 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