Re: [OMPI users] latest Intel CPU bug

[Gilles Gouaillardet]

John,


The technical assessment so to speak is linked in the article and is 
available at 
https://googleprojectzero.blogspot.jp/2018/01/reading-privileged-memory-with-side.html.


The long rant against Intel PR blinded you and you did not notice AMD 
and ARM (and though not mentionned here, Power and Sparc too) are 
vulnerable to some bugs.



Full disclosure, i have no affiliation with Intel, but i am getting 
pissed with the hysteria around this issue.


Gilles


On 1/5/2018 3:54 PM, John Chludzinski wrote:
That article gives the best technical assessment I've seen of Intel's 
architecture bug. I noted the discussion's subject and thought I'd add 
some clarity. Nothing more.


For the TL;DR crowd: get an AMD chip in your computer.

On Thursday, January 4, 2018, r...@open-mpi.org 
 mailto:r...@open-mpi.org>> 
wrote:


Yes, please - that was totally inappropriate for this mailing list.
Ralph



On Jan 4, 2018, at 4:33 PM, Jeff Hammond mailto:jeff.scie...@gmail.com>> wrote:

Can we restrain ourselves to talk about Open-MPI or at least
technical aspects of HPC communication on this list and leave the
stock market tips for Hacker News and Twitter?

Thanks,

Jeff

On Thu, Jan 4, 2018 at 3:53 PM, John
Chludzinskimailto:john.chludzin...@gmail.com>>wrote:


Fromhttps://semiaccurate.com/2018/01/04/kaiser-security-holes-will-devastate-intels-marketshare/





  Kaiser security holes will devastate Intel’s marketshare


  Analysis: This one tips the balance toward AMD in a big way


  Jan 4, 2018 by Charlie Demerjian
  



This latest decade-long critical security hole in Intel CPUs
is going to cost the company significant market share.
SemiAccurate thinks it is not only consequential but will
shift the balance of power away from Intel CPUs for at least
the next several years.

Today’s latest crop of gaping security flaws have three sets
of holes across Intel, AMD, and ARM processors along with a
slew of official statements and detailed analyses. On top of
that the statements from vendors range from detailed and
direct to intentionally misleading and slimy. Lets take a
look at what the problems are, who they effect and what the
outcome will be. Those outcomes range from trivial patching
to destroying the market share of Intel servers, and no we
are not joking.

(*Authors Note 1:* For the technical readers we are
simplifying a lot, sorry we know this hurts. The full
disclosure docs are linked, read them for the details.)

(*Authors Note 2:* For the financial oriented subscribers out
there, the parts relevant to you are at the very end, the
section is titled *Rubber Meet Road*.)

*The Problem(s):*

As we said earlier there are three distinct security flaws
that all fall somewhat under the same umbrella. All are ‘new’
in the sense that the class of attacks hasn’t been publicly
described before, and all are very obscure CPU speculative
execution and timing related problems. The extent the fixes
affect differing architectures also ranges from minor to
near-crippling slowdowns. Worse yet is that all three flaws
aren’t bugs or errors, they exploit correct CPU behavior to
allow the systems to be hacked.

The three problems are cleverly labeled Variant One, Variant
Two, and Variant Three. Google Project Zero was the original
discoverer of them and has labeled the classes as Bounds
Bypass Check, Branch Target Injection, and Rogue Data Cache
Load respectively. You can read up on the extensive and gory
details here


 if
you wish.

If you are the TLDR type the very simplified summary is that
modern CPUs will speculatively execute operations ahead of
the one they are currently running. Some architectures will
allow these executions to start even when they violate
privilege levels, but those instructions are killed or rolled
back hopefully before they actually complete running.

Another feature of modern CPUs is virtual memory which can
allow memory from two or more processes to occupy the same
physical page. This is a good thing because if you have
memory from the kernel and a bit of user code in the same
physical page but different virtual pages, changing from
kernel to userspace execution doesn’t require a page fault.
This saves massive amounts of time and overhead giving modern

Re: [OMPI users] latest Intel CPU bug

[John Chludzinski]

That article gives the best technical assessment I've seen of Intel's
architecture bug. I noted the discussion's subject and thought I'd add some
clarity. Nothing more.

For the TL;DR crowd: get an AMD chip in your computer.

On Thursday, January 4, 2018, r...@open-mpi.org  wrote:

> Yes, please - that was totally inappropriate for this mailing list.
> Ralph
>
>
> On Jan 4, 2018, at 4:33 PM, Jeff Hammond  wrote:
>
> Can we restrain ourselves to talk about Open-MPI or at least technical
> aspects of HPC communication on this list and leave the stock market tips
> for Hacker News and Twitter?
>
> Thanks,
>
> Jeff
>
> On Thu, Jan 4, 2018 at 3:53 PM, John Chludzinski  gmail.com> wrote:
>
>> From https://semiaccurate.com/2018/01/04/kaiser-security-
>> holes-will-devastate-intels-marketshare/
>>
>> Kaiser security holes will devastate Intel’s marketshareAnalysis: This
>> one tips the balance toward AMD in a big wayJan 4, 2018 by Charlie
>> Demerjian 
>>
>>
>>
>> This latest decade-long critical security hole in Intel CPUs is going to
>> cost the company significant market share. SemiAccurate thinks it is not
>> only consequential but will shift the balance of power away from Intel CPUs
>> for at least the next several years.
>>
>> Today’s latest crop of gaping security flaws have three sets of holes
>> across Intel, AMD, and ARM processors along with a slew of official
>> statements and detailed analyses. On top of that the statements from
>> vendors range from detailed and direct to intentionally misleading and
>> slimy. Lets take a look at what the problems are, who they effect and what
>> the outcome will be. Those outcomes range from trivial patching to
>> destroying the market share of Intel servers, and no we are not joking.
>>
>> (*Authors Note 1:* For the technical readers we are simplifying a lot,
>> sorry we know this hurts. The full disclosure docs are linked, read them
>> for the details.)
>>
>> (*Authors Note 2:* For the financial oriented subscribers out there, the
>> parts relevant to you are at the very end, the section is titled *Rubber
>> Meet Road*.)
>>
>> *The Problem(s):*
>>
>> As we said earlier there are three distinct security flaws that all fall
>> somewhat under the same umbrella. All are ‘new’ in the sense that the class
>> of attacks hasn’t been publicly described before, and all are very obscure
>> CPU speculative execution and timing related problems. The extent the fixes
>> affect differing architectures also ranges from minor to near-crippling
>> slowdowns. Worse yet is that all three flaws aren’t bugs or errors, they
>> exploit correct CPU behavior to allow the systems to be hacked.
>>
>> The three problems are cleverly labeled Variant One, Variant Two, and
>> Variant Three. Google Project Zero was the original discoverer of them and
>> has labeled the classes as Bounds Bypass Check, Branch Target Injection,
>> and Rogue Data Cache Load respectively. You can read up on the extensive
>> and gory details here
>> 
>>  if
>> you wish.
>>
>> If you are the TLDR type the very simplified summary is that modern CPUs
>> will speculatively execute operations ahead of the one they are currently
>> running. Some architectures will allow these executions to start even when
>> they violate privilege levels, but those instructions are killed or rolled
>> back hopefully before they actually complete running.
>>
>> Another feature of modern CPUs is virtual memory which can allow memory
>> from two or more processes to occupy the same physical page. This is a good
>> thing because if you have memory from the kernel and a bit of user code in
>> the same physical page but different virtual pages, changing from kernel to
>> userspace execution doesn’t require a page fault. This saves massive
>> amounts of time and overhead giving modern CPUs a huge speed boost. (For
>> the really technical out there, I know you are cringing at this
>> simplification, sorry).
>>
>> These two things together allow you to do some interesting things and
>> along with timing attacks add new weapons to your hacking arsenal. If you
>> have code executing on one side of a virtual memory page boundary, it can
>> speculatively execute the next few instructions on the physical page that
>> cross the virtual page boundary. This isn’t a big deal unless the two
>> virtual pages are mapped to processes that are from different users or
>> different privilege levels. Then you have a problem. (Again painfully
>> simplified and liberties taken with the explanation, read the Google paper
>> for the full detail.)
>>
>> This speculative execution allows you to get a few short (low latency)
>> instructions in before the speculation ends. Under certain circumstances
>> you can read memory from different threads or privilege levels, write those
>> things somewhere, and figure out what addresses other bits of code

Re: [OMPI users] latest Intel CPU bug

[r...@open-mpi.org]

Yes, please - that was totally inappropriate for this mailing list.
Ralph


> On Jan 4, 2018, at 4:33 PM, Jeff Hammond  wrote:
> 
> Can we restrain ourselves to talk about Open-MPI or at least technical 
> aspects of HPC communication on this list and leave the stock market tips for 
> Hacker News and Twitter?
> 
> Thanks,
> 
> Jeff
> 
> On Thu, Jan 4, 2018 at 3:53 PM, John Chludzinski  > wrote:
> From 
> https://semiaccurate.com/2018/01/04/kaiser-security-holes-will-devastate-intels-marketshare/
>  
> 
> 
> Kaiser security holes will devastate Intel’s marketshare
> Analysis: This one tips the balance toward AMD in a big way
> Jan 4, 2018 by Charlie Demerjian 
>  
> 
> This latest decade-long critical security hole in Intel CPUs is going to cost 
> the company significant market share. SemiAccurate thinks it is not only 
> consequential but will shift the balance of power away from Intel CPUs for at 
> least the next several years.
> 
> Today’s latest crop of gaping security flaws have three sets of holes across 
> Intel, AMD, and ARM processors along with a slew of official statements and 
> detailed analyses. On top of that the statements from vendors range from 
> detailed and direct to intentionally misleading and slimy. Lets take a look 
> at what the problems are, who they effect and what the outcome will be. Those 
> outcomes range from trivial patching to destroying the market share of Intel 
> servers, and no we are not joking.
> 
> (Authors Note 1: For the technical readers we are simplifying a lot, sorry we 
> know this hurts. The full disclosure docs are linked, read them for the 
> details.)
> 
> (Authors Note 2: For the financial oriented subscribers out there, the parts 
> relevant to you are at the very end, the section is titled Rubber Meet Road.)
> 
> The Problem(s):
> 
> As we said earlier there are three distinct security flaws that all fall 
> somewhat under the same umbrella. All are ‘new’ in the sense that the class 
> of attacks hasn’t been publicly described before, and all are very obscure 
> CPU speculative execution and timing related problems. The extent the fixes 
> affect differing architectures also ranges from minor to near-crippling 
> slowdowns. Worse yet is that all three flaws aren’t bugs or errors, they 
> exploit correct CPU behavior to allow the systems to be hacked.
> 
> The three problems are cleverly labeled Variant One, Variant Two, and Variant 
> Three. Google Project Zero was the original discoverer of them and has 
> labeled the classes as Bounds Bypass Check, Branch Target Injection, and 
> Rogue Data Cache Load respectively. You can read up on the extensive and gory 
> details here 
> 
>  if you wish.
> 
> If you are the TLDR type the very simplified summary is that modern CPUs will 
> speculatively execute operations ahead of the one they are currently running. 
> Some architectures will allow these executions to start even when they 
> violate privilege levels, but those instructions are killed or rolled back 
> hopefully before they actually complete running.
> 
> Another feature of modern CPUs is virtual memory which can allow memory from 
> two or more processes to occupy the same physical page. This is a good thing 
> because if you have memory from the kernel and a bit of user code in the same 
> physical page but different virtual pages, changing from kernel to userspace 
> execution doesn’t require a page fault. This saves massive amounts of time 
> and overhead giving modern CPUs a huge speed boost. (For the really technical 
> out there, I know you are cringing at this simplification, sorry).
> 
> These two things together allow you to do some interesting things and along 
> with timing attacks add new weapons to your hacking arsenal. If you have code 
> executing on one side of a virtual memory page boundary, it can speculatively 
> execute the next few instructions on the physical page that cross the virtual 
> page boundary. This isn’t a big deal unless the two virtual pages are mapped 
> to processes that are from different users or different privilege levels. 
> Then you have a problem. (Again painfully simplified and liberties taken with 
> the explanation, read the Google paper for the full detail.)
> 
> This speculative execution allows you to get a few short (low latency) 
> instructions in before the speculation ends. Under certain circumstances you 
> can read memory from different threads or privilege levels, write those 
> things somewhere, and figure out what addresses other bits of code are using. 
> The latter bit has the nasty effect of potentially blowing through address 
> space randomization defenses which are a keystone of modern security efforts. 
> It is ugly.
> 
> Who 

Re: [OMPI users] latest Intel CPU bug

[Jeff Hammond]

Can we restrain ourselves to talk about Open-MPI or at least technical
aspects of HPC communication on this list and leave the stock market tips
for Hacker News and Twitter?

Thanks,

Jeff

On Thu, Jan 4, 2018 at 3:53 PM, John Chludzinski  wrote:

> From https://semiaccurate.com/2018/01/04/kaiser-security-holes-
> will-devastate-intels-marketshare/
>
> Kaiser security holes will devastate Intel’s marketshareAnalysis: This
> one tips the balance toward AMD in a big wayJan 4, 2018 by Charlie
> Demerjian 
>
>
>
> This latest decade-long critical security hole in Intel CPUs is going to
> cost the company significant market share. SemiAccurate thinks it is not
> only consequential but will shift the balance of power away from Intel CPUs
> for at least the next several years.
>
> Today’s latest crop of gaping security flaws have three sets of holes
> across Intel, AMD, and ARM processors along with a slew of official
> statements and detailed analyses. On top of that the statements from
> vendors range from detailed and direct to intentionally misleading and
> slimy. Lets take a look at what the problems are, who they effect and what
> the outcome will be. Those outcomes range from trivial patching to
> destroying the market share of Intel servers, and no we are not joking.
>
> (*Authors Note 1:* For the technical readers we are simplifying a lot,
> sorry we know this hurts. The full disclosure docs are linked, read them
> for the details.)
>
> (*Authors Note 2:* For the financial oriented subscribers out there, the
> parts relevant to you are at the very end, the section is titled *Rubber
> Meet Road*.)
>
> *The Problem(s):*
>
> As we said earlier there are three distinct security flaws that all fall
> somewhat under the same umbrella. All are ‘new’ in the sense that the class
> of attacks hasn’t been publicly described before, and all are very obscure
> CPU speculative execution and timing related problems. The extent the fixes
> affect differing architectures also ranges from minor to near-crippling
> slowdowns. Worse yet is that all three flaws aren’t bugs or errors, they
> exploit correct CPU behavior to allow the systems to be hacked.
>
> The three problems are cleverly labeled Variant One, Variant Two, and
> Variant Three. Google Project Zero was the original discoverer of them and
> has labeled the classes as Bounds Bypass Check, Branch Target Injection,
> and Rogue Data Cache Load respectively. You can read up on the extensive
> and gory details here
> 
>  if
> you wish.
>
> If you are the TLDR type the very simplified summary is that modern CPUs
> will speculatively execute operations ahead of the one they are currently
> running. Some architectures will allow these executions to start even when
> they violate privilege levels, but those instructions are killed or rolled
> back hopefully before they actually complete running.
>
> Another feature of modern CPUs is virtual memory which can allow memory
> from two or more processes to occupy the same physical page. This is a good
> thing because if you have memory from the kernel and a bit of user code in
> the same physical page but different virtual pages, changing from kernel to
> userspace execution doesn’t require a page fault. This saves massive
> amounts of time and overhead giving modern CPUs a huge speed boost. (For
> the really technical out there, I know you are cringing at this
> simplification, sorry).
>
> These two things together allow you to do some interesting things and
> along with timing attacks add new weapons to your hacking arsenal. If you
> have code executing on one side of a virtual memory page boundary, it can
> speculatively execute the next few instructions on the physical page that
> cross the virtual page boundary. This isn’t a big deal unless the two
> virtual pages are mapped to processes that are from different users or
> different privilege levels. Then you have a problem. (Again painfully
> simplified and liberties taken with the explanation, read the Google paper
> for the full detail.)
>
> This speculative execution allows you to get a few short (low latency)
> instructions in before the speculation ends. Under certain circumstances
> you can read memory from different threads or privilege levels, write those
> things somewhere, and figure out what addresses other bits of code are
> using. The latter bit has the nasty effect of potentially blowing through
> address space randomization defenses which are a keystone of modern
> security efforts. It is ugly.
>
> *Who Gets Hit:*
>
> So we have three attack vectors and three affected companies, Intel, AMD,
> and ARM. Each has a different set of vulnerabilities to the different
> attacks due to differences in underlying architectures. AMD put out a
> pretty clear statement of what is affected, ARM put out by far the best and
> most comprehensive

Re: [OMPI users] latest Intel CPU bug

[John Chludzinski]

From
https://semiaccurate.com/2018/01/04/kaiser-security-holes-will-devastate-intels-marketshare/

Kaiser security holes will devastate Intel’s marketshareAnalysis: This one
tips the balance toward AMD in a big wayJan 4, 2018 by Charlie Demerjian




This latest decade-long critical security hole in Intel CPUs is going to
cost the company significant market share. SemiAccurate thinks it is not
only consequential but will shift the balance of power away from Intel CPUs
for at least the next several years.

Today’s latest crop of gaping security flaws have three sets of holes
across Intel, AMD, and ARM processors along with a slew of official
statements and detailed analyses. On top of that the statements from
vendors range from detailed and direct to intentionally misleading and
slimy. Lets take a look at what the problems are, who they effect and what
the outcome will be. Those outcomes range from trivial patching to
destroying the market share of Intel servers, and no we are not joking.

(*Authors Note 1:* For the technical readers we are simplifying a lot,
sorry we know this hurts. The full disclosure docs are linked, read them
for the details.)

(*Authors Note 2:* For the financial oriented subscribers out there, the
parts relevant to you are at the very end, the section is titled *Rubber
Meet Road*.)

*The Problem(s):*

As we said earlier there are three distinct security flaws that all fall
somewhat under the same umbrella. All are ‘new’ in the sense that the class
of attacks hasn’t been publicly described before, and all are very obscure
CPU speculative execution and timing related problems. The extent the fixes
affect differing architectures also ranges from minor to near-crippling
slowdowns. Worse yet is that all three flaws aren’t bugs or errors, they
exploit correct CPU behavior to allow the systems to be hacked.

The three problems are cleverly labeled Variant One, Variant Two, and
Variant Three. Google Project Zero was the original discoverer of them and
has labeled the classes as Bounds Bypass Check, Branch Target Injection,
and Rogue Data Cache Load respectively. You can read up on the extensive
and gory details here

if
you wish.

If you are the TLDR type the very simplified summary is that modern CPUs
will speculatively execute operations ahead of the one they are currently
running. Some architectures will allow these executions to start even when
they violate privilege levels, but those instructions are killed or rolled
back hopefully before they actually complete running.

Another feature of modern CPUs is virtual memory which can allow memory
from two or more processes to occupy the same physical page. This is a good
thing because if you have memory from the kernel and a bit of user code in
the same physical page but different virtual pages, changing from kernel to
userspace execution doesn’t require a page fault. This saves massive
amounts of time and overhead giving modern CPUs a huge speed boost. (For
the really technical out there, I know you are cringing at this
simplification, sorry).

These two things together allow you to do some interesting things and along
with timing attacks add new weapons to your hacking arsenal. If you have
code executing on one side of a virtual memory page boundary, it can
speculatively execute the next few instructions on the physical page that
cross the virtual page boundary. This isn’t a big deal unless the two
virtual pages are mapped to processes that are from different users or
different privilege levels. Then you have a problem. (Again painfully
simplified and liberties taken with the explanation, read the Google paper
for the full detail.)

This speculative execution allows you to get a few short (low latency)
instructions in before the speculation ends. Under certain circumstances
you can read memory from different threads or privilege levels, write those
things somewhere, and figure out what addresses other bits of code are
using. The latter bit has the nasty effect of potentially blowing through
address space randomization defenses which are a keystone of modern
security efforts. It is ugly.

*Who Gets Hit:*

So we have three attack vectors and three affected companies, Intel, AMD,
and ARM. Each has a different set of vulnerabilities to the different
attacks due to differences in underlying architectures. AMD put out a
pretty clear statement of what is affected, ARM put out by far the best and
most comprehensive description, and Intel obfuscated, denied, blamed
others, and downplayed the problem. If this was a contest for misleading
with doublespeak and misdirection, Intel won with a gold star, the others
weren’t even in the game. Lets look at who said what and why.

*ARM:*

ARM has a page up  listing
vulnerable processor cores, descriptions of the attacks, and plen

Re: [OMPI users] latest Intel CPU bug

[Reuti]

Am 04.01.2018 um 23:45 schrieb r...@open-mpi.org:

> As more information continues to surface, it is clear that this original 
> article that spurred this thread was somewhat incomplete - probably released 
> a little too quickly, before full information was available. There is still 
> some confusion out there, but the gist from surfing the various articles (and 
> trimming away the hysteria) appears to be:
> 
> * there are two security issues, both stemming from the same root cause. The 
> “problem” has actually been around for nearly 20 years, but faster processors 
> are making it much more visible.
> 
> * one problem (Meltdown) specifically impacts at least Intel, ARM, and AMD 
> processors. This problem is the one that the kernel patches address as it can 
> be corrected via software, albeit with some impact that varies based on 
> application. Those apps that perform lots of kernel services will see larger 
> impacts than those that don’t use the kernel much.
> 
> * the other problem (Spectre) appears to impact _all_ processors (including, 
> by some reports, SPARC and Power). This problem lacks a software solution
> 
> * the “problem” is only a problem if you are running on shared nodes - i.e., 
> if multiple users share a common OS instance as it allows a user to 
> potentially access the kernel information of the other user. So HPC 
> installations that allocate complete nodes to a single user might want to 
> take a closer look before installing the patches. Ditto for your desktop and 
> laptop - unless someone can gain access to the machine, it isn’t really a 
> “problem”.

Weren't there some PowerPC with strict in-order-execution which could 
circumvent this? I find a hint about an "EIEIO" command only. Sure, 
in-order-execution might slow down the system too.

-- Reuti


> 
> * containers and VMs don’t fully resolve the problem - the only solution 
> other than the patches is to limit allocations to single users on a node
> 
> HTH
> Ralph
> 
> 
>> On Jan 3, 2018, at 10:47 AM, r...@open-mpi.org wrote:
>> 
>> Well, it appears from that article that the primary impact comes from 
>> accessing kernel services. With an OS-bypass network, that shouldn’t happen 
>> all that frequently, and so I would naively expect the impact to be at the 
>> lower end of the reported scale for those environments. TCP-based systems, 
>> though, might be on the other end.
>> 
>> Probably something we’ll only really know after testing.
>> 
>>> On Jan 3, 2018, at 10:24 AM, Noam Bernstein  
>>> wrote:
>>> 
>>> Out of curiosity, have any of the OpenMPI developers tested (or care to 
>>> speculate) how strongly affected OpenMPI based codes (just the MPI part, 
>>> obviously) will be by the proposed Intel CPU memory-mapping-related kernel 
>>> patches that are all the rage?
>>> 
>>> 
>>> https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/
>>> 
>>> 
>>> Noam
>>> ___
>>> users mailing list
>>> users@lists.open-mpi.org
>>> https://lists.open-mpi.org/mailman/listinfo/users
>> 
>> ___
>> users mailing list
>> users@lists.open-mpi.org
>> https://lists.open-mpi.org/mailman/listinfo/users
> 
> ___
> users mailing list
> users@lists.open-mpi.org
> https://lists.open-mpi.org/mailman/listinfo/users
> 

___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users

Re: [OMPI users] latest Intel CPU bug

[r...@open-mpi.org]

As more information continues to surface, it is clear that this original 
article that spurred this thread was somewhat incomplete - probably released a 
little too quickly, before full information was available. There is still some 
confusion out there, but the gist from surfing the various articles (and 
trimming away the hysteria) appears to be:

* there are two security issues, both stemming from the same root cause. The 
“problem” has actually been around for nearly 20 years, but faster processors 
are making it much more visible.

* one problem (Meltdown) specifically impacts at least Intel, ARM, and AMD 
processors. This problem is the one that the kernel patches address as it can 
be corrected via software, albeit with some impact that varies based on 
application. Those apps that perform lots of kernel services will see larger 
impacts than those that don’t use the kernel much.

* the other problem (Spectre) appears to impact _all_ processors (including, by 
some reports, SPARC and Power). This problem lacks a software solution

* the “problem” is only a problem if you are running on shared nodes - i.e., if 
multiple users share a common OS instance as it allows a user to potentially 
access the kernel information of the other user. So HPC installations that 
allocate complete nodes to a single user might want to take a closer look 
before installing the patches. Ditto for your desktop and laptop - unless 
someone can gain access to the machine, it isn’t really a “problem”.

* containers and VMs don’t fully resolve the problem - the only solution other 
than the patches is to limit allocations to single users on a node

HTH
Ralph


> On Jan 3, 2018, at 10:47 AM, r...@open-mpi.org wrote:
> 
> Well, it appears from that article that the primary impact comes from 
> accessing kernel services. With an OS-bypass network, that shouldn’t happen 
> all that frequently, and so I would naively expect the impact to be at the 
> lower end of the reported scale for those environments. TCP-based systems, 
> though, might be on the other end.
> 
> Probably something we’ll only really know after testing.
> 
>> On Jan 3, 2018, at 10:24 AM, Noam Bernstein  
>> wrote:
>> 
>> Out of curiosity, have any of the OpenMPI developers tested (or care to 
>> speculate) how strongly affected OpenMPI based codes (just the MPI part, 
>> obviously) will be by the proposed Intel CPU memory-mapping-related kernel 
>> patches that are all the rage?
>> 
>>  
>> https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/
>> 
>>  
>> Noam
>> ___
>> users mailing list
>> users@lists.open-mpi.org
>> https://lists.open-mpi.org/mailman/listinfo/users
> 
> ___
> users mailing list
> users@lists.open-mpi.org
> https://lists.open-mpi.org/mailman/listinfo/users

___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users