Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Spectre Defenses #3804

Open
defuse opened this issue Jan 23, 2019 · 2 comments
Open

Implement Spectre Defenses #3804

defuse opened this issue Jan 23, 2019 · 2 comments
Assignees
Labels
I-performance Problems and improvements with respect to performance I-SECURITY Problems and improvements related to security. side channels special to Taylor

Comments

@defuse
Copy link
Contributor

defuse commented Jan 23, 2019

Given the existence of transient execution attacks Spectre and Meltdown, the inadequacies of current defenses, and unknowns about what other kinds of attacks researchers will discover in the future, it's probably best to tell users "assume your keys can be stolen by other users on the system" as we currently do in security-warnings.md.

However, GCC has a feature we might be able to take advantage of. Quoting from that paper:

Speculative Load Hardening (SLH) is an approach used
by  LLVM  and  was  proposed  by  Carruth  [12].   Using  this
idea, loads are checked using branchless code to ensure that
they  are  executing  along  a  valid  control  flow  path.   To  do
this,  they transform the code at the compiler level and in-
troduce a data dependency on the condition.  In the case of
misspeculation, the pointer is zeroed out, preventing it from
leaking data through speculative execution. One prerequisite
for this approach is hardware that allows implementation of
a branchless and unpredicted conditional update of a regis-
ter’s value. As of now, the feature is only available in LLVM
for x86 as the patch for ARM is still under review.   GCC
adopted the idea of SLH for their implementation, support-
ing both x86 and ARM. They provide a builtin function to
either emit a speculation barrier or return a safe value if it
determines that the instruction is transient [17]
@defuse defuse added I-SECURITY Problems and improvements related to security. special to Taylor side channels labels Jan 23, 2019
@daira
Copy link
Contributor

daira commented Jan 26, 2019

What's the typical performance impact of this approach?

(It's not that I value performance above security, but:

  • this particular approach may or may not be effective;
  • there might be other approaches with less performance impact;
  • we need to know the performance impact anyway.)

Also, does this interact or is it mutually exclusive with other approaches to mitigating transient execution side channels or other attacks? (See the linked paper for examples of such interactions.)

@daira daira added the I-performance Problems and improvements with respect to performance label Jan 26, 2019
@daira daira added this to Needs Prioritization in Arborist Team via automation Jan 26, 2019
@daira
Copy link
Contributor

daira commented Jan 26, 2019

Note that according to Table 7 of the "Systematic Evaluation" paper, SLH only attempts to address Spectre-PHT attacks (the classic attack that tries to bypass bounds checks by exploiting the Pattern History Table, also called Spectre Variant 1).

@mms710 mms710 moved this from Needs Prioritization to Sprint Backlog in Arborist Team Jan 28, 2019
@mms710 mms710 moved this from Bugs/TechDebt Backlog to Security Issue Backlog in Arborist Team May 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-performance Problems and improvements with respect to performance I-SECURITY Problems and improvements related to security. side channels special to Taylor
Projects
Arborist Team
  
Security Issue Backlog
Development

No branches or pull requests

3 participants