llvm dev - Apr 2019 - 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
   -

      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>

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>