[cfe-dev] Clang insertion of fence instructions to mitigate Spectre variant 1?

Chandler Carruth via cfe-dev cfe-dev at lists.llvm.org
Fri Mar 23 04:01:53 PDT 2018


I've posted an RFC about this mitigation approach now:
http://lists.llvm.org/pipermail/llvm-dev/2018-March/122085.html

My patch also happens to implement fence insertion, but the costs seem
prohibitive.

On Thu, Mar 22, 2018 at 3:25 PM Reid Kleckner <rnk at google.com> wrote:

> I know Chandler is working on a different, hopefully less expensive,
> mitigation based on load masking. He has a document that he is polishing
> that should be sent for RFC soon.
>
> On Wed, Mar 21, 2018, 5:59 AM Dallman, John via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> As far as I've been able to learn, the only way to avoid security
>> vulnerabilities due to Spectre variant 1 (CVE-2017-5753, “bounds check
>> bypass”) is to insert fences to control the relevant speculative reads. I'm
>> interested in doing this because I work on a numerical modelling library
>> that is used in many applications, which are used to handle valuable
>> information. There's been at least one piece of malware that specifically
>> targeted one of those applications, so I work at a moderate level of
>> paranoia.
>>
>> I've found information about __builtin_load_no_speculate, but inserting
>> those by hand into ten million lines of branchy C code that's under active
>> development is not an attractive prospect.
>>
>> MSVC has recently gained a /QSpectre option that tries to do this for you
>> (
>> *https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/*
>> <https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/>).
>> It only handles a very limited range of cases at present (
>> *https://www.paulkocher.com/doc/MicrosoftCompilerSpectreMitigation.html*
>> <https://www.paulkocher.com/doc/MicrosoftCompilerSpectreMitigation.html>),
>> but Microsoft are working on improving that. Red Hat tell me that there is
>> work underway to add something similar to GCC, although it's probably a
>> year away.
>>
>> While such a capability can't be completely fool-proof, I can well
>> believe that it's possible to do as good a job as bored humans, and it will
>> be much cheaper.
>>
>> Are there any plans to add something equivalent to Clang?
>>
>> Thanks,
>>
>> --
>> John Dallman
>> DF PL TO OT PC PDE
>> Technology & Innovation
>> *Nullius in verba*
>>
>> Siemens Industry Sector
>> Siemens Industry Software Limited
>> Francis House, 112 Hills Road,
>> <https://maps.google.com/?q=112+Hills+Road,+%0D%0A+Cambridge+CB2&entry=gmail&source=g>
>>
>> <https://maps.google.com/?q=112+Hills+Road,+%0D%0A+Cambridge+CB2&entry=gmail&source=g>
>> Cambridge CB2
>> <https://maps.google.com/?q=112+Hills+Road,+%0D%0A+Cambridge+CB2&entry=gmail&source=g>
>> 1PH, United Kingdom
>> Tel.      :+44 (1223) 371554 <+44%201223%20371554>
>> Fax       :+44 (1223) 371700 <+44%201223%20371700>
>> *john.dallman at siemens.com * <john.dallman at siemens.com>
>> *www.siemens.com/plm * <http://www.siemens.com/plm>
>>
>>
>> -----------------
>> Siemens Industry Software Limited is a limited company registered in
>> England and Wales.
>> Registered number: 3476850.
>> Registered office: Faraday House, Sir William Siemens Square, Frimley,
>> Surrey, GU16 8QD.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180323/a8c00097/attachment.html>


More information about the cfe-dev mailing list