<div dir="ltr"><div>I guess we have all seen this:   <a href="https://access.redhat.com/articles/3307751">https://access.redhat.com/articles/3307751</a></div><div><br></div><div>If not, 'HPC Workloads' (*) such as HPL are 2-5% affected.</div><div>However as someone who recently installed a lot of NVMe drives for a fast filesystem, the 8-19% performance hit on random IO to NVMe drives is not pleasing.</div><div><br></div><div><br></div><div>(*) Quotes are deliberate.  We all know that the best benchmarks are your own applications.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 January 2018 at 12:05, John Hearns <span dir="ltr"><<a href="mailto:hearnsj@googlemail.com" target="_blank">hearnsj@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Disabling branch prediction  - that in itself will have an effect on performance.</div><div><br></div><div>One thing I read about the hardware is that the table which holds the branch predictions is shared between processes running on the same CPU core.</div><div>That is part of the attack process - the malicious process has knowledge of what the 'sharing' process will branch to.</div><div><br></div><div>I float the following idea - perhaps this reinforces good practice for running HPC codes. Meaning cpusets and process pinning, </div><div>which we already do for reasons of performance and for better resource allocation.</div><div>I expose my ignorance here, and wonder if we will see more containerised workloads, which are strictly contained within their own memory space.</div><div>I then answer myself by saying I am talking nonsense, because the kernel routines need to be run somewhere and this exploit is all about being able to probe</div><div>areas of memory which you should not be able to do by speculatively running some instructions and capturing what effect they have.</div><div>And ""their own memory space" is within virtual memory.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 6 January 2018 at 02:26, Christopher Samuel <span dir="ltr"><<a href="mailto:chris@csamuel.org" target="_blank">chris@csamuel.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 06/01/18 12:00, Gerald Henriksen wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For anyone interested this is AMD's response:<br>
<br>
<a href="https://www.amd.com/en/corporate/speculative-execution" target="_blank" rel="noreferrer">https://www.amd.com/en/corpora<wbr>te/speculative-execution</a><br>
</blockquote>
<br></span>
Cool, so variant 1 is likely the one that SuSE has firmware for to<br>
disable branch prediction on Epyc.<br>
<br>
cheers,<span class="m_3171814710367488997im m_3171814710367488997HOEnZb"><br>
Chris<br>
-- <br>
 Chris Samuel  :  <a href="http://www.csamuel.org/" target="_blank" rel="noreferrer">http://www.csamuel.org/</a>  :  Melbourne, VIC<br></span><div class="m_3171814710367488997HOEnZb"><div class="m_3171814710367488997h5">
______________________________<wbr>_________________<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" rel="noreferrer">http://www.beowulf.org/mailman<wbr>/listinfo/beowulf</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>