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

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

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

Peter Smith via llvm-dev
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

  • 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

      • 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

LLVM Developers mailing list
[hidden email]