<div dir="ltr"><div><div><div>There is absolutely no argument from me that the Client side *has* to be patched immediately, my question was only about server side which seems to me to be at a mitigated risk due to the nature of the server.<br></div>I think we'll be switching to vanilla kernel on client side and seeing how that works for us (at least until we migrate to server 2.10.x or 2.11).<br><br></div>Regards,<br></div>Eli<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 6, 2018 at 12:29 AM, Marion Hakanson <span dir="ltr"><<a href="mailto:hakansom@ohsu.edu" target="_blank">hakansom@ohsu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We may not need to apply these mitigations to Lustre servers,<br>
but a lot of Lustre code runs on the client systems.<br>
<br>
Let's say you run a multi-user research cluster;  Lab group A says<br>
that their data must not be seen by any user except those in Lab A, so<br>
user, group, and filesystem permissions are set to implement that policy.<br>
<br>
Lab groups B and C may not have malicious users, but they do download,<br>
compile, and run programs from collaborators, or from the Internet<br>
at large.  So they may inadvertently install and run some malicious<br>
code on that research cluster, and potentially expose Lab group A's<br>
data even though B and C users wouldn't normally have permissions<br>
to do so.<br>
<br>
Do you analyze every bit of code that runs on your research cluster?<br>
We don't have the resources to do so.<br>
<br>
<br>
A possible related issue:  In addition to the kernel-vs-user address space<br>
changes needed for Meltdown, there are also some code changes needed to<br>
prevent the Spectre type of attacks.  Those changes (function call/return<br>
conventions) need to happen in user-space code, but also in the kernel.<br>
I imagine that Lustre code itself could need these mods too, in order<br>
to be protected from attack code on client systems.<br>
<br>
<a href="https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-o
f-Speculative-Execution-Side-Channels.pdf" rel="noreferrer" target="_blank">https://newsroom.intel.com/wp-<wbr>content/uploads/sites/11/2018/<wbr>01/Intel-Analysis-o<br>
f-Speculative-Execution-Side-<wbr>Channels.pdf</a><br>
<br>
I didn't find any items matching "meltdown" or "spectre" in the HPDD<br>
Lustre JIRA just now, so perhaps work hasn't started on this yet.<br>
<br>
Regards,<br>
<br>
Marion<br>
<br>
<br>
<br>
> Date: Fri, 5 Jan 2018 13:31:23 -0500<br>
> From: Mark Hahn <<a href="mailto:hahn@mcmaster.ca">hahn@mcmaster.ca</a>><br>
> To: Lustre discussion <<a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.<wbr>org</a>><br>
> Subject: Re: [lustre-discuss] Are there any performance hits with the<br>
<div class="HOEnZb"><div class="h5">><br>
> > Also to what extent would a Lustre system that is essentially a filer be at<br>
> > risk? It's not running user code and you're not browsing from it...<br>
><br>
> to be vulnerable, attack code must run on the system.<br>
> ______________________________<wbr>_________________<br>
> lustre-discuss mailing list<br>
> <a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.<wbr>org</a><br>
> <a href="http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org" rel="noreferrer" target="_blank">http://lists.lustre.org/<wbr>listinfo.cgi/lustre-discuss-<wbr>lustre.org</a><br>
><br>
<br>
<br>
______________________________<wbr>_________________<br>
lustre-discuss mailing list<br>
<a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.<wbr>org</a><br>
<a href="http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org" rel="noreferrer" target="_blank">http://lists.lustre.org/<wbr>listinfo.cgi/lustre-discuss-<wbr>lustre.org</a><br>
</div></div></blockquote></div><br></div>