EuroLLVM 2019 - Spectre Round Table Notes

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

  • Related link:

  • 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.

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.