<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:"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:12.0pt;
        font-family:"Times New Roman",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;}
span.m-6193516357112197540hoenzb
        {mso-style-name:m_-6193516357112197540hoenzb;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.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;}
--></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"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Perhaps it’s more about “system management” for HPC – these sort of vulnerabilities only occur when you have one process able to see what’s going on in another
 process.  From a “security” standpoint, the answer is simple – don’t share the same entity between processes owned by different users. (presumably a given user doesn’t care about “leaking” from one of his/her processes to another).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Sure, in the abstract, it would be nice to design leakproof processors – hey, it would be nice to make processors and hardware that don’t radiate EMI, which can
 also provide a leakage path.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I’m not sure that for the *<b>vast majority</b>* of HPC applications this is a problem – sure, in “the cloud” or in a heavily shared resource with very little
 control over who is sharing (i.e. Azure or AWS kind of server farming) you’ve got a potential problem.  And, on the desktop where a seemingly innocuous program can theoretically get data from another.   Neither of the latter, though, is anything like what
 one would consider “secure computing”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If the data YOU are processing is sufficiently valuable that it is worth it to try and exploit via a Spectre type attack,  maybe it’s worth it for you to have
 a dedicated computing resource?  Are HPC jobs sufficiently fine grained and disperseable that you would have multiple user’s processes running on a single CPU in a 1000 node cluster? Or would you say “User 1, you get nodes 1-500, User 2 you get nodes 501-1000”? 
 I find it hard to believe that we *<b>must</b>* distribute processes more finely grained than this (user 1 gets cores 1,2,3,4 on node1, cores 1,2 on node2, user 2 gets cores 3,4, on node 2, cores 1,2,3,4 on node 3)<br>
<br>
And really, these Spectre type attacks are sort of a theoretical vulnerability – there’s a long way from having iron ore and reading about its processing to having machine tools and swords in your hands.  Sure, there are adversaries with sufficient resources
 to figure it out (maybe it’s cheaper to steal secrets than to do it yourself, if the original secrets cost billions), and it’s of great theoretical interest to figure out how to make processors that are immune to this.  But really, is this a significant threat? 
 Or, even more “conspiracy theory”, you create this potential threat which is *<b>very</b>* expensive to counter, so you throw all your resources at it, and starve the mitigation of the other threats.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">For all those millions of dollars you’d invest in “industrializing” an attack like Spectre, you could go out and bribe employees and probably achieve the same
 end result.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">James Lux<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Task Manager, DARPA High Frequency Research (DHFR) Space Testbed<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Jet Propulsion Laboratory  (Mail Stop 161-213)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">4800 Oak Grove Drive<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Pasadena CA 91109<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">(818)354-2075 (office)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">(818)395-2714 (cell)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Beowulf [mailto:beowulf-bounces@beowulf.org]
<b>On Behalf Of </b>Scott Atchley<br>
<b>Sent:</b> Tuesday, July 17, 2018 6:38 AM<br>
<b>To:</b> John Hearns <hearnsj@googlemail.com><br>
<b>Cc:</b> Beowulf Mailing List <beowulf@beowulf.org><br>
<b>Subject:</b> Re: [Beowulf] New Spectre attacks - no software mitigation - what impact for HPC?<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I saw that article as well. It seems like they are targeting using RISC-V to build an accelerator. One could argue that you do not need speculation within a GPU-like accelerator, but you have to get your performance from very wide execution
 units with lots of memory requests in flight as a GPU does today.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Jul 17, 2018 at 8:19 AM, John Hearns via Beowulf <<a href="mailto:beowulf@beowulf.org" target="_blank">beowulf@beowulf.org</a>> wrote:<o:p></o:p></p>
<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">This article is well worth a read, on European Exascale projects<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://www.theregister.co.uk/2018/07/17/europes_exascale_supercomputer_chips/" target="_blank">https://www.theregister.co.uk/2018/07/17/europes_exascale_supercomputer_chips/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The automotive market seems to have got mixed in there also!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The main thrust  dual ARM based and RISC-V<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Also I like the plexiglass air shroud pictured at Barcelona. I saw something similar at the HPE centre in Grenoble.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Damn good idea.<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"><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"><o:p> </o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 17 July 2018 at 13:07, Scott Atchley <<a href="mailto:e.scott.atchley@gmail.com" target="_blank">e.scott.atchley@gmail.com</a>> wrote:<o:p></o:p></p>
<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 Chris,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">They say that no announced silicon is vulnerable. Your link makes it clear that no ISA is immune if the implementation performs speculative execution. I think your point about two lines of production may make sense. Vendors will have to
 assess vulnerabilities and the performance trade-off.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Personally, I do not see a large HPC system being built out of non-speculative hardware. You would need much more hardware to reach a level of performance and the additional power could lead to a lower performance per Watt (i.e., exceed
 the facility's power budget).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">Scott<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Jul 17, 2018 at 2:33 AM, Chris Samuel <<a href="mailto:chris@csamuel.org" target="_blank">chris@csamuel.org</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">On Tuesday, 17 July 2018 11:08:42 AM AEST Chris Samuel wrote:<br>
<br>
> Currently these new vulnerabilities are demonstrated on Intel & ARM, it will<br>
> be interesting to see if AMD is also vulnerable (I would guess so).<br>
<br>
Interestingly RISC-V claims immunity, and that looks like it'll be one of the <br>
two CPU architectures blessed by the Europeans in their Exascale project <br>
(along with ARM).<br>
<br>
<a href="https://riscv.org/2018/01/more-secure-world-risc-v-isa/" target="_blank">https://riscv.org/2018/01/more-secure-world-risc-v-isa/</a><br>
<br>
All the best,<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Chris<br>
-- <br>
 Chris Samuel  :  <a href="http://www.csamuel.org/" target="_blank">http://www.csamuel.org/</a>  :  Melbourne, VIC<br>
<br>
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">
http://www.beowulf.org/mailman/listinfo/beowulf</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">
http://www.beowulf.org/mailman/listinfo/beowulf</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">
http://www.beowulf.org/mailman/listinfo/beowulf</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>