Re: [OMPI users] latest Intel CPU bug

[Jeff Hammond]

An article with "market share" in the title is not a technical assessment,
but in any case, you aren't willing to respect the request to focus on
Open-MPI on the Open-MPI list, so I'll be piping mail from your address to
trash from now on.

Jeff

On Thu, Jan 4, 2018 at 10:54 PM, John Chludzinski <
john.chludzin...@gmail.com> 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  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-hol
>>> es-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 

Re: [OMPI users] latest Intel CPU bug

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

That is enough, folks. This is an email forum for users to get help regarding 
Open MPI, not a place to vent your feelings about specific vendors. We ask that 
you respect that policy and refrain from engaging in such behavior.

We don’t care if you are quoting someone else - the fact that “Mikey said it” 
doesn’t justify violating the policy. So please stop this here and now.

Thank you
Ralph


> On Jan 5, 2018, at 6:09 AM, John Chludzinski  
> wrote:
> 
> I believe this snippet sums it up pretty well:
> 
> "Now you have a bit more context about why Intel’s response was, well, a 
> non-response. They blamed others, correctly, for having the same problem but 
> their blanket statement avoided the obvious issue of the others aren’t 
> crippled by the effects of the patches like Intel. Intel screwed up, badly, 
> and are facing a 30% performance hit going forward for it. AMD did right and 
> are probably breaking out the champagne at HQ about now."
> 
> On Fri, Jan 5, 2018 at 5:38 AM, Matthieu Brucher  > wrote:
> Hi,
> 
> I think, on the contrary, that he did notice the AMD/ARM issue. I suppose you 
> haven't read the text (and I like the fact that there are different opinions 
> on this issue).
> 
> Matthieu
> 
> 2018-01-05 8:23 GMT+01:00 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  
> >    >> 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
>  >>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
> 

Re: [OMPI users] latest Intel CPU bug

[Ray Sheppard]

Hello All,
  Please people, just drop it.  I appreciated the initial post in 
response to to the valid question of how these bugs might impact OMPI 
and message passing in general.  At this point, y'all are beating the 
proverbial dead horse.  If you wish to debate, please mail each other 
directly.  Thank you.

   Ray

On 1/5/2018 9:09 AM, John Chludzinski wrote:

I believe this snippet sums it up pretty well:

"Now you have a bit more context about why Intel’s response was, well, 
a non-response. They blamed others, correctly, for having the same 
problem but their blanket statement avoided the obvious issue of the 
others aren’t crippled by the effects of the patches like Intel. Intel 
screwed up, badly, and are facing a 30% performance hit going forward 
for it. AMD did right and are probably breaking out the champagne at 
HQ about now."


On Fri, Jan 5, 2018 at 5:38 AM, Matthieu Brucher 
> wrote:


Hi,

I think, on the contrary, that he did notice the AMD/ARM issue. I
suppose you haven't read the text (and I like the fact that there
are different opinions on this issue).

Matthieu

2018-01-05 8:23 GMT+01:00 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
 >  >> 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
    >>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
   

Re: [OMPI users] latest Intel CPU bug

[John Chludzinski]

I believe this snippet sums it up pretty well:

"Now you have a bit more context about why Intel’s response was, well, a
non-response. They blamed others, correctly, for having the same problem
but their blanket statement avoided the obvious issue of the others aren’t
crippled by the effects of the patches like Intel. Intel screwed up, badly,
and are facing a 30% performance hit going forward for it. AMD did right
and are probably breaking out the champagne at HQ about now."

On Fri, Jan 5, 2018 at 5:38 AM, Matthieu Brucher  wrote:

> Hi,
>
> I think, on the contrary, that he did notice the AMD/ARM issue. I suppose
> you haven't read the text (and I like the fact that there are different
> opinions on this issue).
>
> Matthieu
>
> 2018-01-05 8:23 GMT+01:00 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-privil
>> eged-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 
>>> > 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>wrote:

 Fromhttps://semiaccurate.com/2018/01/04/kaiser-security-hole
 s-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 

Re: [OMPI users] latest Intel CPU bug

[Matthieu Brucher]

Hi,

I think, on the contrary, that he did notice the AMD/ARM issue. I suppose
you haven't read the text (and I like the fact that there are different
opinions on this issue).

Matthieu

2018-01-05 8:23 GMT+01:00 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-privil
> eged-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 
>> > 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>> >wrote:
>>>
>>> Fromhttps://semiaccurate.com/2018/01/04/kaiser-security-hole
>>> s-will-devastate-intels-marketshare/
>>> >> 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
>>> >> ileged-memory-with-side.html> 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 

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 
 > 
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>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 

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
>> 

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 

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 

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 

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

Re: [OMPI users] latest Intel CPU bug

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

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

[OMPI users] latest Intel CPU bug

[Noam Bernstein]

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