[llvm-dev] EuroLLVM 2019 - Spectre Round Table Notes

[Zola Bridges via llvm-dev]

A quick update about the test suite mentioned in these notes. The
beginnings have been released on Github in case anyone is interested in
checking it out or contributing.

https://github.com/google/safeside

Zola Bridges


On Fri, Apr 19, 2019 at 1:46 PM Zola Bridges <zbrid at google.com> wrote:

> I put together some notes about the round table. I cc'd each person who
> gave me their email addresses at the event as well.
>
> EuroLLVM 2019 - April 8, 2019
>
>
>    -
>
>    Current API load/costs/perf hits
>    -
>
>       ARM - data flow tracking part of mitigations is about ⅔ of the
>       overhead, can possibly get it down to 50%
>       -
>
>       Google - saw the same wrt data flow tracking. Also noted that in
>       the non-public Google spot API the specific code path with the spot
>       mitigation had a higher cost than the code path with Speculative Load
>       Hardening
>       -
>
>    Test suites that show mitigations work
>    -
>
>       People at Google are planning to work on this. Right now there are
>       mainly small, non-public proofs of concept.
>       -
>
>    ARM API history
>    -
>
>       Originally the ARM spot mitigation API was quickly put together to
>       meet the disclosure deadline. It has evolved since then, but not based on
>       usage from users.
>       -
>
>       ARM would like to hear from users about their experience working
>       with Spectre mitigations.
>       -
>
>    People at Google are working on doc with suggestions on how to
>    mitigate with respect to Spectre
>    -
>
>    Suggested reading from discussion of possible mitigation that didn't
>    seem viable: Why Spectre is Here to Stay
>    -
>
>       https://arxiv.org/abs/1902.05178
>       -
>
>    How do the API creators know they are correcting the right things?
>    -
>
>       Intel has a test suite where they check things are properly
>       mitigated.
>       -
>
>    Challenging questions for users: How to answer: What does this
>    security mean for the end user? Is it worth it to mitigate this?
>    -
>
>       If you want safety, you can add separate address spaces.
>       -
>
>       Consider SLH and other mitigations as tools in a toolbox. You don't
>       have to use them all.
>       -
>
>       Can be useful to rethink the app design when possible
>       -
>
>       Sometimes there are things you may not consider secrets, but are
>       important for security (for example: what apps are running at the same time
>       as another on an Android device,)
>       -
>
>       Improve isolation models?
>       -
>
>          Automatic isolation by the compiler was discussed
>          -
>
>             Related link:
>             https://www.cl.cam.ac.uk/research/security/ctsrd/soaap/
>             -
>
>             There is work in the functional language community about this
>             -
>
>                Haskell model of heap isolation
>                -
>
>          Across isolation boundaries, other APIs may need to be
>          specified. Could create surface layer validations and accompanying tests.
>          -
>
>    Guidance on libc++?
>    -
>
>       Depends on if you're using libc++ with secrets
>       -
>
>       No specific guidance needed other than you have be to more specific
>       about the exact problem you're solving.
>       -
>
>    Can we be less reactive in responses to these and related issues?
>    -
>
>       Possibly by designing isolation models up front rather than only
>       applying mitigations as leaks are found
>       -
>
>    Can we create an automated tool for threat modelling?
>    -
>
>       Probably not because it's too idiosyncratic to the specific
>       application.
>       -
>
>    Discussed static analyzers
>    -
>
>       Have been around 10
>       -
>
>          Either too many false positives or false negatives which made
>          them unusable
>          -
>
>       Google may publish info about their internal static analyzer design
>       -
>
>    Can we get spec exec mitigation coverage by fuzz testing?
>    -
>
>       Fuzz testing results in a lack of theoretical coverage, but we can
>       do enough fuzzing to know it's unlikely there are holes cheap enough for
>       attackers to find and use.
>       -
>
>    Sanitizer + Fuzzer
>    -
>
>       Chandler C. had an idea about making a sanitizer for speculative
>       execution vulnerability mitigations. He said he'll write a doc about this.
>
>
> Feel free to discuss.
>
> Zola Bridges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190914/03a311df/attachment.html>