<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<span class="">Hi Chandler,</span>
<div class=""><br class="">
<div class=""><span class="">Thank you very much for sharing this!</span></div>
<div class=""><span class=""><br class="">
</span><span class="">The RFC is pretty lengthy but the far majority of it makes sense to me. I’m sure I’m forgetting to react to some aspects below, but I thought I’d summarize some initial thoughts and questions I had after reading the RFC end-to-end.</span></div>
<div class=""><br class="">
* I believe the same high-level principles you outline can also be used to implement the same protection on the Arm instruction sets (AArch64 and AArch32). The technique you describe is dependent on being able to do an “<span style="color: rgb(34, 34, 34);" class="">unpredicted
conditional update of a register's value"</span>. For the Arm architecture, the guarantee for the conditional update to be unpredicted can come from using the new CSDB instruction – see documentation at <a href="https://developer.arm.com/support/security-update/download-the-" class="">https://developer.arm.com/support/security-update/download-the-</a>whitepaper.</div>
<div class=""><span class=""><br class="">
</span><span class="">* It seems you suggest 2 ways to protect against side-channel attacks leaking speculatively-loaded secret data: either protect by zero-ing out address bits that may represent secret data, or zero-ing out loaded data. In the first case
(zero-ing out address bits) – wouldn’t you have to apply that to addresses used in stores too, next to addresses used in loads?</span></div>
<div class=""><span class=""><br class="">
</span><span class="">* IIUC, you state that constant-offset stack locations and global variables don’t need protection. For option 1 (zero-ing out the address bit that may represent secret data) – I can understand the rationale for why constant offset stack
locations and global variables don’t need protection. But I’m wondering what the detailed rationale is for not needing protection on option 2 (zero-ing out the value loaded): what guarantees that no secret info can be located on the stack or in a global variable?
Or did I misunderstand the proposal?</span></div>
<div class=""><span class=""><br class="">
</span><span class="">* For x86 specifically, you explain how the low 2gb and high 2gb of address space should be protected by the OS. I wonder if this +-2gb range could be reduced sharply by letting the compiler not generate 32 bit constant offsets in address
calculations, but at most a much smaller constant offset? I assume limiting that may have only a very small effect on code quality – and might potentially ease the requirements on the OS?<br class="">
</span><span class=""> </span></div>
<div class=""><span class=""><br class="">
</span><span class="">Thanks!</span><span class=""><br class="">
<br class="">
</span><span class="">Kristof<br class="">
<br class="">
</span><span class=""><br class="">
</span>
<div>
<blockquote type="cite" class="">
<div class="">On 23 Mar 2018, at 11:56, Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Hello all,
<div class=""><br class="">
</div>
<div class="">I've been working for the last month or so on a comprehensive mitigation approach to variant #1 of Spectre. There are a bunch of reasons why this is desirable:</div>
<div class="">- Critical software that is unlikely to be easily hand-mitigated (or where the performance tradeoff isn't worth it) will have a compelling option.</div>
<div class="">- It gives us a baseline on performance for hand-mitigation.</div>
<div class="">- Combined with opt-in or opt-out, it may give simpler hand-mitigation.</div>
<div class="">- It is instructive to see *how* to mitigate code patterns.</div>
<div class=""><br class="">
</div>
<div class="">A detailed design document is available for commenting here:</div>
<div class=""><a href="https://docs.google.com/document/d/1wwcfv3UV9ZnZVcGiGuoITT_61e_Ko3TmoCS3uXLcJR0/edit" class="">https://docs.google.com/document/d/1wwcfv3UV9ZnZVcGiGuoITT_61e_Ko3TmoCS3uXLcJR0/edit</a></div>
<div class="">(I pasted this in markdown format at the bottom of the email as well.)<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">I have also published a very early prototype patch that implements this design:</div>
<div class=""><a href="https://reviews.llvm.org/D44824" class="">https://reviews.llvm.org/D44824</a></div>
<div class="">This is the patch I've used to collect the performance data on the approach. It should be fairly functional but is a long way from being ready to review in detail, much less land. I'm posting so folks can start seeing the overall approach and
can play with it if they want. Grab it here:</div>
<div class=""><br class="">
</div>
<div class="">Comments are very welcome! I'd like to keep the doc and this thread focused on discussion of the high-level technique for hardening, and the code review thread for discussion of the techniques used to implement this in LLVM.</div>
<div class=""><br class="">
</div>
<div class="">Thanks all!</div>
<div class="">-Chandler</div>
<div class="">
<div class="">….</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</body>
</html>