<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:476070410;
mso-list-template-ids:1418757090;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:934941368;
mso-list-type:hybrid;
mso-list-template-ids:-1153275894 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:945039770;
mso-list-template-ids:1810676606;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3
{mso-list-id:1133718807;
mso-list-template-ids:633386034;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">I’m not in a position to provide some concrete use cases, but there are at least some users for whom manual mitigation of inline assembly is too much of a burden. I think a prudent approach would be to provide an opt-in flag to enable automated
mitigation of inline assembly, a kind of yes-I-know-what-I-am-doing feature, where we make it clear that the feature carries at least two caveats:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo4">Bytecode may be left unmitigated.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo4">If the correctness of the inline assembly code depends on the number of bytes in any contiguous code sequence (e.g., a manually computed jump table), then the mitigation may break
the code.<o:p></o:p></li></ol>
<p class="MsoNormal">The GNU features that Matt pointed to have these same caveats.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>Matthew Riley via llvm-dev<br>
<b>Sent:</b> Wednesday, March 25, 2020 3:21 PM<br>
<b>To:</b> James Y Knight <jyknight@google.com><br>
<b>Cc:</b> llvm-dev <llvm-dev@lists.llvm.org>; Topper, Craig <craig.topper@intel.com><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Speculative Execution Side Effect Suppression for Mitigating Load Value Injection<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I'm also a bit unclear on that point. I think one input here has to be: what are some example, existing codebases we want to mitigate, and what should the user experience be to mitigate them? I don't think we can make good engineering tradeoffs
without having concrete use cases to evaluate.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Another point: it seems some mitigation options have already been
<a href="https://www.phoronix.com/scan.php?page=news_item&px=GNU-Assembler-LVI-Options">
added to the GNU toolchain</a>. We should try very hard to make sure the experience doesn't diverge unnecessarily between users of gcc and clang. <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Mar 20, 2020 at 6:02 PM James Y Knight <<a href="mailto:jyknight@google.com">jyknight@google.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">One question I have is regarding the mitigation for inline or standalone assembly files. Generally, I dislike having the assembler mangle code -- it should just emit exactly what you ask it to, and not be "smart", and such mitigations are
really best done in the compiler.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">But, if there is going to be an implementation of these mitigations added to assembly (which there's some movement towards doing, although I'm not clear as to the outcome) it's not clear to me that doing it in
<i>both</i> places is important. Do we really need both?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Mar 20, 2020 at 6:14 PM Zola Bridges via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hi everyone!<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I want to clarify the purpose and design of SESES. Thus far, I've characterized it as an LVI mitigation which is somewhat incorrect.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">SESES was built as a "big hammer." It is intended to protect against many side channel vulnerabilities (Spectre v1, Spectre v4, LVI, etc, etc) even though it was built in response to LVI.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For folks protecting against LVI, this is an option for mitigation. This is also an option for folks who want to try to mitigate against speculative execution vulnerabilities as a whole and who don't have high performance needs. As mentioned
in the documentation this is not necessarily foolproof, but it's as close as we can get to closing all side channels. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Zola Bridges<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Mar 18, 2020 at 2:03 PM Zola Bridges <<a href="mailto:zbrid@google.com" target="_blank">zbrid@google.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">Hi everyone,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Scott and I have been working to make our patches upstreamable. I'd like to hear more feedback.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I would only upstream my patches if the community felt it would be beneficial/desirable. It would be nice to have more discussion to make it easier to make a decision within the next week or two.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What are your thoughts on the following topics?<o:p></o:p></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
Should SESES be upstreamed? Are there any concerns about upstreaming it?<o:p></o:p></li></ul>
<ul type="disc">
<ul type="circle">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1">
<a href="https://reviews.llvm.org/D75939" target="_blank"><span style="font-family:"Arial",sans-serif">https://reviews.llvm.org/D75939</span></a><o:p></o:p></li></ul>
</ul>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
Should Scott's approach be upstreamed? Are there any concerns about upstreaming it?<o:p></o:p></li></ul>
<ul type="disc">
<ul type="circle">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1">
<a href="https://reviews.llvm.org/D75937" target="_blank">https://reviews.llvm.org/D75937</a><o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1">
<a href="http://lists.llvm.org/pipermail/llvm-dev/2020-March/139842.html" target="_blank"><span style="font-family:"Arial",sans-serif">http://lists.llvm.org/pipermail/llvm-dev/2020-March/139842.html</span></a><o:p></o:p></li></ul>
</ul>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
Are there reasons to upstream both approaches?<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
Are there reasons against upstreaming both approaches?<o:p></o:p></li></ul>
<div>
<p class="MsoNormal">I'm particularly interested in hearing from folks who may use one of these mitigations. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For example, Jethro from Fortanix provided feedback (in the #backends Discord channel) that he would be most interested in seeing Scott approach upstreamed due to the performance advantage.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Zola Bridges<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Tue, Mar 10, 2020 at 10:23 AM Zola Bridges <<a href="mailto:zbrid@google.com" target="_blank">zbrid@google.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Hi everyone,</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Some Intel processors have a newly disclosed vulnerability named Load Value Injection.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">One pager on Load Value Injection:</span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><a href="https://software.intel.com/security-software-guidance/software-guidance/load-value-injection" target="_blank"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#1A73E8">https://software.intel.com/security-software-guidance/software-guidance/load-value-injection</span></a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Deep dive on Load Value Injection:</span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#1A73E8"><a href="https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection" target="_blank">https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection</a>
</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">I wrote this compiler pass that can be used as a last resort mitigation. This pass is based on ideas from Chandler Carruth and Intel. This pass is primarily
intended to share with the community as a basis for experimentation and may not be production ready. We are open to upstreaming this pass if there is interest from the community. It can be removed if it becomes a maintenance burden.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Intel has also created a mitigation that they have shared:
</span><a href="http://lists.llvm.org/pipermail/llvm-dev/2020-March/139842.html" target="_blank"><span style="font-family:"Arial",sans-serif">http://lists.llvm.org/pipermail/llvm-dev/2020-March/139842.html</span></a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">We look forward to sharing information and ideas about both.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">The documentation in this email lists the performance I saw for variants of the mitigation that are potential optimizations for Load Value Injection. The flags
can be used to turn on optimization techniques for different builds. They are turned off by default. Each variant is not guaranteed to be as secure as the full mitigation.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Here is a link to the first patch:
</span><a href="https://reviews.llvm.org/D75939" target="_blank"><span style="font-family:"Arial",sans-serif">https://reviews.llvm.org/D75939</span></a><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Here is a link to the documentation patch:
</span><a href="https://reviews.llvm.org/D75940" target="_blank"><span style="font-family:"Arial",sans-serif">https://reviews.llvm.org/D75940</span></a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Links to other related patches</span><o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li style="color:black;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l3 level1 lfo2;vertical-align:baseline;font-variant-numeric:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:"Arial",sans-serif"><a href="https://reviews.llvm.org/D75941" target="_blank">https://reviews.llvm.org/D75941</a><o:p></o:p></span></li><li style="color:black;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l3 level1 lfo2;vertical-align:baseline;font-variant-numeric:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:"Arial",sans-serif"><a href="https://reviews.llvm.org/D75942" target="_blank">https://reviews.llvm.org/D75942</a><o:p></o:p></span></li><li style="color:black;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l3 level1 lfo2;vertical-align:baseline;font-variant-numeric:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:"Arial",sans-serif"><a href="https://reviews.llvm.org/D75944" target="_blank">https://reviews.llvm.org/D75944</a><o:p></o:p></span></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">I'd like to request comments, feedback, and discussion. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Beyond that, we would also like guidance on whether to upstream this pass.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Thanks,</span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">Zola Bridges</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><b><span style="font-family:"Arial",sans-serif;color:black">From the documentation: Overview of the mitigation</span></b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">As the name suggests, the "speculative execution side effect suppression" mitigation aims to prevent any effects of speculative execution from escaping into
the microarchitectural domain where they could be observed, thereby closing off side channel information leaks.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">In the case of Load Value Injection, we assume that speculative loads from memory (due to explicit memory access instructions or control flow instructions like
RET) may receive injected data due to address aliasing, and we ensure these injected values are not allowed to steer later speculative memory accesses to impact cache contents.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">The mitigation is implemented as a compiler pass that inserts a speculation barrier (LFENCE) just before:</span><o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li style="color:black;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l2 level1 lfo3;vertical-align:baseline;font-variant-numeric:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:"Arial",sans-serif">Each memory read instruction<o:p></o:p></span></li><li style="color:black;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l2 level1 lfo3;vertical-align:baseline;font-variant-numeric:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:"Arial",sans-serif">Each memory write instruction<o:p></o:p></span></li><li style="color:black;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l2 level1 lfo3;vertical-align:baseline;font-variant-numeric:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:"Arial",sans-serif">The first branch instruction in a group of terminators at the end of a basic block<o:p></o:p></span></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">This is something of a last-resort mitigation: it is expected to have
<i>extreme</i> performance implications and it may not be a <i>complete</i> mitigation because it relies on enumerating specific side channel mechanisms. However, it is applicable to more variants and styles of gadgets that can reach speculative execution side
channels than just traditional Spectre Variant 1 gadgets which speculative load hardening (SLH) targets much more narrowly but more efficiently.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">While there is a slight risk that this mitigation will be ineffective against future side channels, we believe there is still significant value in closing two
side channel classes that are most actively exploited today: control-flow based (branch predictor or icache) and cache timing. Control flow side channels are closed by preventing speculative execution into conditionals and indirect branches. Cache timing side
channels are closed by preventing speculative execution of reads and writes.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-family:"Arial",sans-serif;color:black">We believe this mitigation will be most useful in situations where code is handling extremely sensitive secrets that must not leak, and where a hit to performance
is tolerable in service of that overriding goal. As we've mentioned, the original target of this mitigation was the threat of LVI against SGX enclaves instrumenting critically important secrets.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</div>
</div>
</body>
</html>