[llvm-dev] RFC: Speculative Load Hardening (a Spectre variant #1 mitigation)

[via llvm-dev]

I understand where the whitelist idea comes from, but if you are executing in a protected domain you need to assume all data needs to be hidden.  The only exception is something explicitly passed back across the domain boundary, per specification of some API.  This is just a reality of system security.

I say this as someone who spent half of a long career in software security:  People really excel at building insecure systems.  Giving them more tools to make mistakes with is totally the wrong approach.  I went back to compilers because dealing with those folks was giving me ulcers.

I hope this doesn't come across as harsh or anything, I have very strong feelings on this and I'm not great at expressing it.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Friedman, Eli via llvm-dev
Sent: Wednesday, July 11, 2018 2:24 PM
To: Chandler Carruth; Kristof Beyls
Cc: llvm-dev; nd
Subject: Re: [llvm-dev] RFC: Speculative Load Hardening (a Spectre variant #1 mitigation)

On 7/11/2018 4:02 AM, Chandler Carruth via llvm-dev wrote:

I believe this approach has the advantage that:
a) it makes it possible to only insert a mitigation in specific locations if
   the programmer is capable of inserting intrinsics manually.

This is definitely an area of great interest long-term.

Annotating specific loads that need to be protected seems like a trap to me.  See https://reviews.llvm.org/D41761#989799 .  (And Bounds Check Bypass Store variants open up other possibilities, like overwriting a spill slot.)

Maybe we can come up with some workable approach to "whitelist" certain pointers: a pointer could be marked "speculatively-dereferenceable(N)" if it points to N bytes of non-secret data.  (We could apply this as load metadata, like !dereferenceable, or it could be explicitly applied using an intrinsic.)

-Eli


--

Employee of Qualcomm Innovation Center, Inc.

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180711/cff790f0/attachment.html>