[llvm] r347628 - Revert "[clang][slh] add attribute for speculative load hardening"
Zola Bridges via llvm-commits
llvm-commits at lists.llvm.org
Mon Nov 26 18:22:01 PST 2018
Author: zbrid
Date: Mon Nov 26 18:22:00 2018
New Revision: 347628
URL: http://llvm.org/viewvc/llvm-project?rev=347628&view=rev
Log:
Revert "[clang][slh] add attribute for speculative load hardening"
until I figure out why the build is failing or timing out
***************************
Summary:
The prior diff had to be reverted because there were two tests
that failed. I updated the two tests in this diff
clang/test/Misc/pragma-attribute-supported-attributes-list.test
clang/test/SemaCXX/attr-speculative-load-hardening.cpp
LLVM IR already has an attribute for speculative_load_hardening. Before
this commit, when a user passed the -mspeculative-load-hardening flag to
Clang, every function would have this attribute added to it. This Clang
attribute will allow users to opt into SLH on a function by function
basis.
This can be applied to functions and Objective C methods.
Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54915
This reverts commit a5b3c232d1e3613f23efbc3960f8e23ea70f2a79.
(r347617)
Modified:
llvm/trunk/docs/LangRef.rst
Modified: llvm/trunk/docs/LangRef.rst
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LangRef.rst?rev=347628&r1=347627&r2=347628&view=diff
==============================================================================
--- llvm/trunk/docs/LangRef.rst (original)
+++ llvm/trunk/docs/LangRef.rst Mon Nov 26 18:22:00 2018
@@ -1643,15 +1643,19 @@ example:
``speculative_load_hardening``
This attribute indicates that
`Speculative Load Hardening <https://llvm.org/docs/SpeculativeLoadHardening.html>`_
- should be enabled for the function body.
-
- Speculative Load Hardening is a best-effort mitigation against
- information leak attacks that make use of control flow
- miss-speculation - specifically miss-speculation of whether a branch
- is taken or not. Typically vulnerabilities enabling such attacks are
- classified as "Spectre variant #1". Notably, this does not attempt to
- mitigate against miss-speculation of branch target, classified as
- "Spectre variant #2" vulnerabilities.
+ should be enabled for the function body. This is a best-effort attempt to
+ mitigate all known speculative execution information leak vulnerabilities
+ that are based on the fundamental principles of modern processors'
+ speculative execution. These vulnerabilities are classified as "Spectre
+ variant #1" vulnerabilities typically. Notably, this does not attempt to
+ mitigate any vulnerabilities where the speculative execution and/or
+ prediction devices of specific processors can be *completely* undermined
+ (such as "Branch Target Injection", a.k.a, "Spectre variant #2"). Instead,
+ this is a target-independent request to harden against the completely
+ generic risk posed by speculative execution to incorrectly load secret data,
+ making it available to some micro-architectural side-channel for information
+ leak. For a processor without any speculative execution or predictors, this
+ is expected to be a no-op.
When inlining, the attribute is sticky. Inlining a function that carries
this attribute will cause the caller to gain the attribute. This is intended
More information about the llvm-commits
mailing list