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

[Zola Bridges 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
   -

      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/20190419/975554ce/attachment.html>