Re: Intel Chip flaw (and some AMD/ARM tested too)

[Charles Mills]

It's astounding what is going on under the covers. You have this simple 
step-by-step mental model of execution -- and it is functionally or 
"observationally" correct* -- but what is actually going on with speculative 
execution and caching is simply astounding. 

*Except when it is not, such as with these vulnerabilities.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Sunday, January 7, 2018 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw (and some AMD/ARM tested too)

Thanks, that's a really good explanation - starting with the basics and 
building up to "Putting it all together" where I finally got lost :)  I will 
try again later.

It's interesting to know that the Raspberry Pi 3 on my desk does not do 
speculative processing, making it immune to the issues.  And as an occasional 
mainframe assembler programmer, I never imagined so much could be going on 
under the covers.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw (and some AMD/ARM tested too)

[Mike Schwab]

It all was tried on the Strech mainframe in the 1950s, late S/370
processors + 1980+, and Intel since the Pentiums.

On Sun, Jan 7, 2018 at 4:00 PM, Tom Brennan  wrote:
> Thanks, that's a really good explanation - starting with the basics and
> building up to "Putting it all together" where I finally got lost :)  I will
> try again later.
>
> It's interesting to know that the Raspberry Pi 3 on my desk does not do
> speculative processing, making it immune to the issues.  And as an
> occasional mainframe assembler programmer, I never imagined so much could be
> going on under the covers.
>
>
> don isenstadt wrote:
>>
>> Here is another write up..
>>
>>
>> https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw (and some AMD/ARM tested too)

[Tom Brennan]

Thanks, that's a really good explanation - starting with the basics and 
building up to "Putting it all together" where I finally got lost :)  I 
will try again later.


It's interesting to know that the Raspberry Pi 3 on my desk does not do 
speculative processing, making it immune to the issues.  And as an 
occasional mainframe assembler programmer, I never imagined so much 
could be going on under the covers.


don isenstadt wrote:

Here is another write up..

https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw (and some AMD/ARM tested too)

[don isenstadt]

Here is another write up..

https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Paul Gilmartin]

On Thu, 4 Jan 2018 12:03:11 -0600, Mike Schwab wrote:

>On Thu, Jan 4, 2018 at 11:41 AM, Raja Mohan wrote:
>> Redhat did confirm in their advisory that it impacts Linux on Z. we may have 
>> to wait on IBM to confirm if it impacts z/OS, z/VM and z/VSE
>>
>IBM, if it finds it, will only issue a patch without details.
>
This raises an interesting challenge to IBM's and other suppliers'
practice of embargoing discussion of security flaws until patches
are available.

Reportedly, Meltdown/Spectre arises from a widespread design oversight
which long went unrecognized.  Repairs may be slow to appear if they
require new microcode or new CPU designs.

There some mitigation may be possible and very desirable in software
changes, even to open-source software -- I've read that Javascript may
provide an avenue of attack.

So necessary details must be disseminated to open-source developers
to craft patches and to testers to reproduce exploits and verify mitigation.
This is a broad target of not ideally disciplined technicians.

""Three May Keep a Secret if Two are Dead"
-- Benjamin Franklin

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AW: Re: Intel Chip flaw

[Edward Finnell]

With the Legacy Database Server z/Db2I.19? Code named 'zippity two da'.


In a message dated 1/6/2018 3:16:19 AM Central Standard Time, p...@gmx.ch 
writes:

 
I imagine some clever marketing guy at IBM: "The *first* release of the all new 
IBM flagship operating system coming out in *2019* will be z/OS V1.19" Or, will 
it be Z/OS V1.19? 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Intel Chip flaw

[Peter Hunkeler]

>LOL, I meant z/OS 1.9. I don't believe a z/OS 1.19 will ever see the light of 
>day.



LOL, why not? Because IBM has logic behind numbering product versions and 
release? I remember:
- OS/390 V1.3. Next release was OS/390 V2.4.
- IBM z900, followed by IBM z990 followed by IBM z9.


I imagine some clever marketing guy at IBM: "The *first* release of the all new 
IBM flagship operating system coming out in *2019* will be z/OS V1.19"  Or, 
will it be Z/OS V1.19?  


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Seymour J Metz]

No, but expect other issues, since you're talking about new architectures that 
haven't yet been vetted.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, January 4, 2018 8:06 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Intel Chip flaw

On Thu, 4 Jan 2018 05:07:03 -0600, Elardus Engelbrecht wrote:
>
>Now, those algorithms are exploited. Basically, you load a 'fetch protected' 
>address and then use/mis-use 'out of order execution' and 'speculative 
>execution' while messing around with the contents of CPU caches.
>
>Long story, but in short, before you are interrupted because of fetch 
>protection, you can dump protected areas to somewhere else.
>
Is this likely to get worse with quantum computers, which are vastly more 
speculative?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Edward Finnell]

Didn't search archives but there was a guy that managed to get a PC game loaded 
into the local printer. Not sure of brand. Big cut-sheet jobber...


In a message dated 1/5/2018 7:49:19 AM Central Standard Time, 
arno...@us.ibm.com writes:

 
with a model that already lets everything access all memory and resources - 
since you don't expect people to be adding malicious code to your embedded 
device.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Kittell, Christopher J]

I read a 3% to 50% performance hit, depending on workload.  I don't know what 
kind of workload does what though.  My guess is lots of small transactions will 
be hit.

Chris Kittell


U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.

-


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Todd Arnold]

Remember that in order to exploit these, you need to be able to load and run 
your own code next to the code you're trying to attack.  You generally can't do 
that in embedded devices like printers, routers, POS terminals, etc.  Also, 
these are attacks that apply to systems running multiple processes that are 
protected from each other using hardware features - but a lot of embedded 
devices only run one process, or run with a model that already lets everything 
access all memory and resources - since you don't expect people to be adding 
malicious code to your embedded device.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Allan Staller]

How many Viruses did it encounter? 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Thursday, January 4, 2018 3:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw

Dana,

I'm asking this more out of ignorance than anything else.  Would the front-end 
terminal need to specifically comply with PCI if it is merely a data entry 
device and isn't actually storing any information?  Not knowing how Walmart's 
systems are set up, if the XP machine and scanner are hard wired to a back end 
server that stores and forwards all the data, wouldn't that be the machine that 
needs to be PCI compliant?

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Thursday, January 04, 2018 2:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw

How can that possibly pass PCI?

On Thu, 4 Jan 2018 12:17:41 -0800, Tom Brennan  
wrote:

>Edward Finnell wrote:
>> ... Just for curiosity's sake I watched the self-serve terminal boot at 
>> Walmart last night. Sure enough-powered by Intel/ Windows XP.
>
>That may actually be a benefit, assuming the CPU is as old as XP and
>perhaps not susceptible.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER:: 

 The contents of this e-mail and any attachment(s) are confidential and 
intended for the named recipient(s) only. E-mail transmission is not guaranteed 
to be secure or error-free as information could be intercepted, corrupted, 
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents (with or without referred errors) 
shall therefore not attach any liability on the originator or HCL or its 
affiliates. Views or opinions, if any, presented in this email are solely those 
of the author and may not necessarily reflect the views or opinions of HCL or 
its affiliates. Any form of reproduction, dissemination, copying, disclosure, 
modification, distribution and / or publication of this message without the 
prior written consent of authorized representative of HCL is strictly 
prohibited. If you have received this email in error please delete it and 
notify the sender immediately. Before opening any email and/or attachments, 
please check them for viruses and other defects. 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Mark Jacobs - Listserv]

The IBM Security/Integrity portal has the information you're seeking.

Mark Jacobs

> David Crayford 
> January 5, 2018 at 7:09 AM
>
>
> Indeed. And there are Linux patches for AMD WRT RDSTC speculation
> exploits
> https://github.com/openSUSE/kernel/commit/6a334d96b8c8924357e2c692c305066f512ec1b8.
>
>
>
> IBM remain tight lipped about z/OS exploits but are releasing patches
> for POWER which shares a similar DNA to Z, so I wonder if there are
> vulnerabilities.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> Please be alert for any emails that may ask you for login information
> or directs you to login via a link. If you believe this message is a
> phish or aren't sure whether this message is trustworthy, please send
> the original message as an attachment to 'phish...@timeinc.com'.
>
> Cannaerts, Jan 
> January 5, 2018 at 4:53 AM
> >Example code is already out there
> >https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6
> .
> I
> >built this on my PC and it worked! Is there a zArch instruction to flush
> >a cache line like the _mm_clflush() built-in for x86? If so it would be
> >easy to compile and run spectre.c on z/OS and see what happens.
>
> Parts of Spectre consist of training the branch predictor to predict
> that the
> branch will go to an address you want it to perform speculative
> execution on.
> The research teams have targeted Intel's Haswell line in particular
> for this.
>
> It also relies on the branch predictor masking the addresses in the branch
> target buffer. The higher parts of the addresses are ignored, giving
> much more
> freedom to the attacker. Furthermore the entries in the BTB are not
> linked to
> an invididual address-space. The branch predictor will use a
> prediction that
> it was trained from in address space A, in address space B. I don't know
> enough about branch prediction on z/Arch to tell you if it's as
> trainable as
> the Intel or AMD branch predictors.
>
> And as you said, you need some control over what lives in the cache
> and what
> does not. There are some z/Arch instructions to mark cached data as no
> longer
> important, but the PoP specifically mentions that the CPU does not
> necessarily
> remove the data from cache. You can trick the CPU in to filling the
> cache with
> junk that you're using in a dummy process though.
>
> The code in the example is still Intel specific. AMD is an "Intel
> clone", as far
> as instruction set and behavior goes, but they differ on a microcode
> level.
> x86 and z/Arch differ in many more ways.
>
> -
> Jan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> Please be alert for any emails that may ask you for login information
> or directs you to login via a link. If you believe this message is a
> phish or aren't sure whether this message is trustworthy, please send
> the original message as an attachment to 'phish...@timeinc.com'.
>

-- 

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[David Crayford]

On 5/01/2018 5:53 PM, Cannaerts, Jan wrote:

And as you said, you need some control over what lives in the cache and what
does not. There are some z/Arch instructions to mark cached data as no longer
important, but the PoP specifically mentions that the CPU does not necessarily
remove the data from cache. You can trick the CPU in to filling the cache with
junk that you're using in a dummy process though.

The code in the example is still Intel specific. AMD is an "Intel clone", as far
as instruction set and behavior goes, but they differ on a microcode level.
x86 and z/Arch differ in many more ways.


Indeed. And there are Linux patches for AMD WRT RDSTC speculation 
exploits 
https://github.com/openSUSE/kernel/commit/6a334d96b8c8924357e2c692c305066f512ec1b8. 



IBM remain tight lipped about z/OS exploits but are releasing patches 
for POWER which shares a similar DNA to Z, so I wonder if there are 
vulnerabilities.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Edward Finnell]

Don't know about the guts, but the externals are all new. Looks to be some 
hybrid that starts up and checks all the stuff and then brings up XP. 


In a message dated 1/4/2018 2:17:54 PM Central Standard Time, 
t...@tombrennansoftware.com writes:

 
That may actually be a benefit, assuming the CPU is as old as XP and 

perhaps not susceptible.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Cannaerts, Jan]

>Example code is already out there
>https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6. I
>built this on my PC and it worked! Is there a zArch instruction to flush
>a cache line like the _mm_clflush() built-in for x86? If so it would be
>easy to compile and run spectre.c on z/OS and see what happens.

Parts of Spectre consist of training the branch predictor to predict that the
branch will go to an address you want it to perform speculative execution on.
The research teams have targeted Intel's Haswell line in particular for this.

It also relies on the branch predictor masking the addresses in the branch
target buffer. The higher parts of the addresses are ignored, giving much more
freedom to the attacker. Furthermore the entries in the BTB are not linked to 
an invididual address-space. The branch predictor will use a prediction that
it was trained from in address space A, in address space B. I don't know
enough about branch prediction on z/Arch to tell you if it's as trainable as
the Intel or AMD branch predictors.

And as you said, you need some control over what lives in the cache and what
does not. There are some z/Arch instructions to mark cached data as no longer
important, but the PoP specifically mentions that the CPU does not necessarily
remove the data from cache. You can trick the CPU in to filling the cache with
junk that you're using in a dummy process though.

The code in the example is still Intel specific. AMD is an "Intel clone", as far
as instruction set and behavior goes, but they differ on a microcode level.
x86 and z/Arch differ in many more ways.

-
Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Elardus Engelbrecht]

Cannaerts, Jan wrote:

>We'll most likely never find out whether or not this flaw exists on z/Arch, as 
>IBM is going to patch this. I'd try it out but I have neither the time nor the 
>hardware.

Big Blue is already aware about this.

Look at https://www.ibm.com/blogs/psirt/potential-cpu-security-issue/ 

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[David Crayford]

On 5/01/2018 5:10 PM, Cannaerts, Jan wrote:

If a similar attack works, as long as it's addressable, you can read it.
I do not exactly know where the DAT tables live, and if they, or the real 
address
they reside at are in fetch-protected common storage, you could get a hold of 
them.
But regardless, I do not believe you can read using real addresses without
executing privileged instructions at some point.

We'll most likely never find out whether or not this flaw exists on z/Arch, as
IBM is going to patch this. I'd try it out but I have neither the time nor
the hardware.


Example code is already out there 
https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6. I 
built this on my PC and it worked! Is there a zArch instruction to flush 
a cache line like the _mm_clflush() built-in for x86? If so it would be 
easy to compile and run spectre.c on z/OS and see what happens.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Cannaerts, Jan]

The (three differnet) Intel flaws rely on "speculative execution". As the CPU
executes both possible execution paths after a branch, the incorrect path's work
is not "committed". Intel's fetch protection is only raised as each instruction
is committed. As a result, you can fetch protected memory, and load other
(unprotected) memory to a register depending on whether or not the contents of
the protected memory were a certain value. Everything you loaded disappears as
the branch target is resolved with certainty, but the (unprotected) memory you
fetched is now in cache. If you fetch it again you can time whether or not it 
was
in cache, showing you if the "speculative execution" loaded the piece of
unprotected memory or not, effectively leaking the contents of the protected
memory.

The other one relies on the same principle, except you perform speculative
execution during out-of-order execution of instructions. You let the CPU perform
work when you know that X instructions earlier, you're going to receive an
exception. So you handle the exception, and the out-of-order instructions that 
were already executed are rolled back, but can leave traces in cache.

While unlikely, it's not unthinkable that z/Architecture is susceptible to a 
similar attack. It all depends on when the CPU raises the protection exception.
Do the pipelines of an unresolved branch stall as soon as an instruction fetches
protected memory? Or is it raised as the CPU tries to commit the pipeline's 
work?

If a similar attack works, as long as it's addressable, you can read it.
I do not exactly know where the DAT tables live, and if they, or the real 
address
they reside at are in fetch-protected common storage, you could get a hold of 
them.
But regardless, I do not believe you can read using real addresses without 
executing privileged instructions at some point.

We'll most likely never find out whether or not this flaw exists on z/Arch, as
IBM is going to patch this. I'd try it out but I have neither the time nor
the hardware.


-
Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Sankaranarayanan, Vignesh]

Got an acknowledgement post from syszsec today.

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: 05 January 2018 06:37
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw

On Thu, 4 Jan 2018 05:07:03 -0600, Elardus Engelbrecht wrote:
>
>Now, those algorithms are exploited. Basically, you load a 'fetch protected' 
>address and then use/mis-use 'out of order execution' and 'speculative 
>execution' while messing around with the contents of CPU caches.
>
>Long story, but in short, before you are interrupted because of fetch 
>protection, you can dump protected areas to somewhere else.
>
Is this likely to get worse with quantum computers, which are vastly more 
speculative?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Paul Gilmartin]

On Thu, 4 Jan 2018 05:07:03 -0600, Elardus Engelbrecht wrote:
>
>Now, those algorithms are exploited. Basically, you load a 'fetch protected' 
>address and then use/mis-use 'out of order execution' and 'speculative 
>execution' while messing around with the contents of CPU caches. 
>
>Long story, but in short, before you are interrupted because of fetch 
>protection, you can dump protected areas to somewhere else.
>
Is this likely to get worse with quantum computers, which are vastly more 
speculative?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[David L. Craig]

On 18Jan04:1432-0800, Charles Mills wrote:

> On 18Jan04:1406-0500, David L. Craig wrote:
> 
> > On 18Jan04:1603-0600, Dana Mitchell wrote:
> > 
> > > I assume IBM will soon patch any Intel based HMC's and SE's.
> > 
> > Why?  Theoretically nothing can get in there to attempt any mischief.
> 
> You don't think like an auditor LOL.

Oh, I do.  I'd LOVE to audit those keys to the customer.
I briefly debated appending the ;-) and thought it
unnecessary.  Alas, nobody I know is in a position to
keep IBM honest on those "appliances".
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Adam Johanson]

I missed the mark a little with, "z/OS 1.19"

LOL, I meant z/OS 1.9. I don't believe a z/OS 1.19 will ever see the light of 
day.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[zMan]

1.19?

On Thu, Jan 4, 2018 at 5:36 PM, Adam Johanson 
wrote:

> John, you mentioned:
>
> 
> Of course, this is a lot of "overhead" and would
> likely cause upper level management to explode in rage and force me to put
> it in key 8 CSA unencrypted for "ease of use".
> 
>
> This wouldn't work indefinitely, as the Announcement for z/OS 2.3
> indicated that 2.3 will be the last release to support
> ALLOWUSERKEYCSA(YES). I think the default was changed from YES to NO in
> z/OS 1.19 as a shot across the bow.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Adam Johanson]

John, you mentioned:


Of course, this is a lot of "overhead" and would
likely cause upper level management to explode in rage and force me to put
it in key 8 CSA unencrypted for "ease of use".


This wouldn't work indefinitely, as the Announcement for z/OS 2.3 indicated 
that 2.3 will be the last release to support ALLOWUSERKEYCSA(YES). I think the 
default was changed from YES to NO in z/OS 1.19 as a shot across the bow.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Phil Smith]

Dana Mitchell wrote:
>Rex, anything that touches cardholder data is in scope:


True, unless the data is encrypted in the actual terminal (the swipey part), as 
it might be with Voltage SecureData. The POS terminal would then never touch 
actual card data, and thus be out of scope.

Or maybe they have compensating controls in place (not that I can imagine what 
those might be!) that allow use of XP...
--

...phsiii

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise
Distinguished Technologist


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Charles Mills]

You don't think like an auditor LOL.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David L. Craig
Sent: Thursday, January 4, 2018 2:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw

On 18Jan04:1603-0600, Dana Mitchell wrote:

> I assume IBM will soon patch any Intel based HMC's and SE's.

Why?  Theoretically nothing can get in there to attempt any mischief.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[David L. Craig]

On 18Jan04:1603-0600, Dana Mitchell wrote:

> I assume IBM will soon patch any Intel based HMC's and SE's.

Why?  Theoretically nothing can get in there to attempt
any mischief.
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Dana Mitchell]

I assume IBM will soon patch any Intel based HMC's and SE's.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Dana Mitchell]

Rex, anything that touches cardholder data is in scope:

The PCI DSS security requirements apply to all system components included in or 
connected
to the cardholder data environment. The cardholder data environment (CDE) is 
comprised of
people, processes, and technologies that store, process, or transmit cardholder 
data or
sensitive authentication data.
Dana

On Thu, 4 Jan 2018 21:25:15 +, Pommier, Rex  wrote:

>Dana,
>
>I'm asking this more out of ignorance than anything else.  Would the front-end 
>terminal need to specifically comply with PCI if it is merely a data entry 
>device and isn't actually storing any information?  Not knowing how Walmart's 
>systems are set up, if the XP machine and scanner are hard wired to a back end 
>server that stores and forwards all the data, wouldn't that be the machine 
>that needs to be PCI compliant?
>
>Rex
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Pommier, Rex]

Dana,

I'm asking this more out of ignorance than anything else.  Would the front-end 
terminal need to specifically comply with PCI if it is merely a data entry 
device and isn't actually storing any information?  Not knowing how Walmart's 
systems are set up, if the XP machine and scanner are hard wired to a back end 
server that stores and forwards all the data, wouldn't that be the machine that 
needs to be PCI compliant?

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Thursday, January 04, 2018 2:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw

How can that possibly pass PCI?

On Thu, 4 Jan 2018 12:17:41 -0800, Tom Brennan  
wrote:

>Edward Finnell wrote:
>> ... Just for curiosity's sake I watched the self-serve terminal boot at 
>> Walmart last night. Sure enough-powered by Intel/ Windows XP.
>
>That may actually be a benefit, assuming the CPU is as old as XP and
>perhaps not susceptible.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Dana Mitchell]

How can that possibly pass PCI?

On Thu, 4 Jan 2018 12:17:41 -0800, Tom Brennan  
wrote:

>Edward Finnell wrote:
>> ... Just for curiosity's sake I watched the self-serve terminal boot at 
>> Walmart last night. Sure enough-powered by Intel/ Windows XP.
>
>That may actually be a benefit, assuming the CPU is as old as XP and
>perhaps not susceptible.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Tom Brennan]

Edward Finnell wrote:

... Just for curiosity's sake I watched the self-serve terminal boot at Walmart 
last night. Sure enough-powered by Intel/ Windows XP.


That may actually be a benefit, assuming the CPU is as old as XP and 
perhaps not susceptible.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Edward Finnell]

We'll have to see how it shakes out. Just from heuristic point of view it would 
seem the z114/ZBX would have heightened exposure. But think about how pervasive 
this is going to be. Peripherals to include printers, PC's, HMC, SE,routers and 
switches. Then there's all the imbedded stuff. Just for curiosity's sake I 
watched the self-serve terminal boot at Walmart last night. Sure enough-powered 
by Intel/ Windows XP.


In a message dated 1/4/2018 7:19:59 AM Central Standard Time, 
kees.verno...@klm.com writes:

 
What I understood is, that Linux, Windows and Apple OS's are vulnerable. The 
leak is in the way memory areas of different tasks are isloated from each 
other. I doubt that zSystems / zArchitecture are vulnerable to this bug.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[John McKown]

On Thu, Jan 4, 2018 at 12:26 PM, Charles Mills  wrote:

> My very amateur reading of the paper is that it affects fetch-protected
> memory that is otherwise addressable by the intruder. So my wild guess is
> that it would affect fetch-protected common storage on any Z OS, but would
> not allow an intruder to read data in another address space. But my degree
> of certainty on the above analysis is very low.
>

​I have a "name" for a programmer who puts sensitive information into z/OS
"common" storage. But it would make your LCD screen explode and then melt.​
Personally, if I needed to keep a password, or other sensitive information:
(1) it would never be "in the clear" and (2) the encrypted value would be
held in either my address space or a SCOPE=SINGLE data space. If "somebody
else" needs to "use" the data somehow, it would invoke the accessor routine
via a PC-ss instruction. Of course, this is a lot of "overhead" and would
likely cause upper level management to explode in rage and force me to put
it in key 8 CSA unencrypted for "ease of use". And yes, I've heard of
things like this (not exactly this) being done.



>
> Charles
>


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Charles Mills]

My very amateur reading of the paper is that it affects fetch-protected memory 
that is otherwise addressable by the intruder. So my wild guess is that it 
would affect fetch-protected common storage on any Z OS, but would not allow an 
intruder to read data in another address space. But my degree of certainty on 
the above analysis is very low.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Raja Mohan
Sent: Thursday, January 4, 2018 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw

Redhat did confirm in their advisory that it impacts Linux on Z. we may have to 
wait on IBM to confirm if it impacts z/OS, z/VM and z/VSE

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Mike Schwab]

On Thu, Jan 4, 2018 at 11:41 AM, Raja Mohan  wrote:
> Redhat did confirm in their advisory that it impacts Linux on Z. we may have 
> to wait on IBM to confirm if it impacts z/OS, z/VM and z/VSE
>
IBM, if it finds it, will only issue a patch without details.

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Raja Mohan]

Redhat did confirm in their advisory that it impacts Linux on Z. we may have to 
wait on IBM to confirm if it impacts z/OS, z/VM and z/VSE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[David L. Craig]

On 18Jan04:1030-0600, Tom Marchant wrote:

> On Thu, 4 Jan 2018 04:11:22 -0600, Cannaerts, Jan wrote:
> 
> >This article: 
> >https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html
> >
> >Mentions the following:
> >
> >> Additional exploits for other architectures are also known to exist. These
> >> include IBM System Z,  POWER8 (Big Endian and Little Endian), and POWER9
> >> (Little Endian).
> 
> If that page mentions Z or Power, I don't see it.

RedHat published the article that does:
https://access.redhat.com/security/vulnerabilities/speculativeexecution?sc_cid=701600127NJAAY
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Charles Mills]

> you'd fetch protect what you didn't want fetched

You might just fetch protect on GP. I cache data in common storage that is
of fairly low "exploit value" but I fetch protect it because I can with
little trouble (and to possibly make prospects with checklists happy).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Martin Packer
Sent: Thursday, January 4, 2018 2:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw

Surely the term "fetch-protected" says it all: In principle you'd fetch
protect what you didn't want fetched. :-) Now, I don't know if there is any
overhead to fetch protection that might cause you not to fetch protect what 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Charles Mills]

I don't see the reference to System Z in the article. Am I missing something?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cannaerts, Jan
Sent: Thursday, January 4, 2018 2:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw

This article: 
https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html

Mentions the following:

> Additional exploits for other architectures are also known to exist. 
> These include IBM System Z,  POWER8 (Big Endian and Little Endian), 
> and POWER9 (Little Endian).

The attacks target flaws in the hardware, in this case related to speculative 
execution. But the PoCs I'm seeing so far seem to be meant to leak Linux kernel 
memory (leaking passwords/cryptographic keys). The z/Architecture also employs 
speculative execution and branch prediction.

So I'm not sure whether or not there is a working PoC for any Linux 
distribution running either Linux native, under z/VM or KVM on System Z, and I 
cannot find anything about a PoC for z/OS either.

If the attack can be used against z/OS, I'd wager it could leak fetch-protected 
memory that is addressable by the address space in the first place. How much 
interesting information there is in fetch-protected storage, I do not know.

-
Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Tom Marchant]

On Thu, 4 Jan 2018 04:11:22 -0600, Cannaerts, Jan wrote:

>This article: 
>https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html
>
>Mentions the following:
>
>> Additional exploits for other architectures are also known to exist. These
>> include IBM System Z,  POWER8 (Big Endian and Little Endian), and POWER9
>> (Little Endian).

If that page mentions Z or Power, I don't see it.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw (and some AMD/ARM tested too)

[Tom Brennan]

Wow... what a writeup!  I'll never understand even 1% of it.  What I did 
learn so far is that when you find something like this, you need to make 
up cool names like Spectre and Meltdown.


Cannaerts, Jan wrote:

This article: 
https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html

Mentions the following:



Additional exploits for other architectures are also known to exist. These
include IBM System Z,  POWER8 (Big Endian and Little Endian), and POWER9
(Little Endian).



The attacks target flaws in the hardware, in this case related to speculative
execution. But the PoCs I'm seeing so far seem to be meant to leak Linux kernel
memory (leaking passwords/cryptographic keys). The z/Architecture also
employs speculative execution and branch prediction.

So I'm not sure whether or not there is a working PoC for any Linux distribution
running either Linux native, under z/VM or KVM on System Z, and I cannot find
anything about a PoC for z/OS either.

If the attack can be used against z/OS, I'd wager it could leak fetch-protected
memory that is addressable by the address space in the first place. How much
interesting information there is in fetch-protected storage, I do not know.

-
Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Vernooij, Kees (ITOPT1) - KLM]

What I understood is, that Linux, Windows and Apple OS's are vulnerable. The 
leak is in the way memory areas of different tasks are isloated from each 
other. I doubt that zSystems / zArchitecture are vulnerable to this bug.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: 04 January, 2018 14:08
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Intel Chip flaw
> 
> This is interesting. And I've been following some of the discussion over
> on
> "Vulture Central",
> http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_
> registers_annotations/
> . But as I understand it, this is a hardware bug on Intel. And there is
> no
> indication that the IBMZ architecture has a similar bug in it. In
> addition,
> even if such a exploit exists on the IBMZ, it seems (as I read it) to be
> only "active" on z/Linux and would be much more difficult to use on z/OS
> or
> z/VSE. I am basing this on the fact that most of the z/OS sensitive
> information is not kept in "common storage" and simply fetch protected.
> At
> least in z/OS, the "UNIX kernel" data is kept in the BPXOINIT address
> space, which is not "common", and is not mapped into the user's address
> space (as the "kernel" data areas are in Linux & Windows). Likewise for
> things such as the "master scheduler" (ASID 1) data, ENQ control blocks,
> and most other things. z/OS is not a microkernel, but is closer to one
> than
> is Linux. As least as well as I understand such things. Which ain't
> necessarily all that much on a theoretical basis.
> 
> On Thu, Jan 4, 2018 at 4:35 AM, Martin Packer 
> wrote:
> 
> > Surely the term "fetch-protected" says it all: In principle you'd
> fetch
> > protect what you didn't want fetched. :-) Now, I don't know if there
> is
> > any overhead to fetch protection that might cause you not to fetch
> protect
> > what should be.
> >
> > Cheers, Martin
> >
> > Martin Packer
> >
> > zChampion, Systems Investigator & Performance Troubleshooter, IBM
> >
> > +44-7802-245-584
> >
> > email: martin_pac...@uk.ibm.com
> >
> > Twitter / Facebook IDs: MartinPacker
> >
> > Blog:
> > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> >
> > Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/
> or
> >
> > https://itunes.apple.com/gb/podcast/mainframe-performance-
> > topics/id1127943573?mt=2
> >
> >
> > Youtube channel:
> https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
> >
> >
> >
> > From:   "Cannaerts, Jan" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date:   04/01/2018 10:11
> > Subject:Re: Intel Chip flaw
> > Sent by:IBM Mainframe Discussion List  m...@listserv.ua.edu>
> >
> >
> >
> > This article:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> > googleprojectzero.blogspot.be_2018_01_reading-2Dprivileged-
> > 2Dmemory-2Dwith-2Dside.html&d=DwIFaQ&c=jf_iaSHvJObTbx-
> > siA1ZOg&r=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ&m=
> > JgfLm1WtVuc3hfiKug2jNzxJ50Cb-S25nq4BySZ38Fs&s=
> > z8S5H15LmNsZT976WrrTR3zjzYH6V6IUtFklSLCiQzE&e=
> >
> >
> > Mentions the following:
> >
> > > Additional exploits for other architectures are also known to exist.
> > These
> > > include IBM System Z,  POWER8 (Big Endian and Little Endian), and
> POWER9
> > > (Little Endian).
> >
> > The attacks target flaws in the hardware, in this case related to
> > speculative
> > execution. But the PoCs I'm seeing so far seem to be meant to leak
> Linux
> > kernel
> > memory (leaking passwords/cryptographic keys). The z/Architecture also
> > employs speculative execution and branch prediction.
> >
> > So I'm not sure whether or not there is a working PoC for any Linux
> > distribution
> > running either Linux native, under z/VM or KVM on System Z, and I
> cannot
> > find
> > anything about a PoC for z/OS either.
> >
> > If the attack can be used against z/OS, I'd wager it could leak
> > fetch-protected
> > memory that is addressable by the address space in the first place.
> How
> > much
> > interesting information there is in fetch-protected storage, I do not
> > know.
> >
> > -
> > Jan
> >
> > -

Re: Intel Chip flaw

[John McKown]

This is interesting. And I've been following some of the discussion over on
"Vulture Central",
http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/
. But as I understand it, this is a hardware bug on Intel. And there is no
indication that the IBMZ architecture has a similar bug in it. In addition,
even if such a exploit exists on the IBMZ, it seems (as I read it) to be
only "active" on z/Linux and would be much more difficult to use on z/OS or
z/VSE. I am basing this on the fact that most of the z/OS sensitive
information is not kept in "common storage" and simply fetch protected. At
least in z/OS, the "UNIX kernel" data is kept in the BPXOINIT address
space, which is not "common", and is not mapped into the user's address
space (as the "kernel" data areas are in Linux & Windows). Likewise for
things such as the "master scheduler" (ASID 1) data, ENQ control blocks,
and most other things. z/OS is not a microkernel, but is closer to one than
is Linux. As least as well as I understand such things. Which ain't
necessarily all that much on a theoretical basis.

On Thu, Jan 4, 2018 at 4:35 AM, Martin Packer 
wrote:

> Surely the term "fetch-protected" says it all: In principle you'd fetch
> protect what you didn't want fetched. :-) Now, I don't know if there is
> any overhead to fetch protection that might cause you not to fetch protect
> what should be.
>
> Cheers, Martin
>
> Martin Packer
>
> zChampion, Systems Investigator & Performance Troubleshooter, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or
>
> https://itunes.apple.com/gb/podcast/mainframe-performance-
> topics/id1127943573?mt=2
>
>
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
> From:   "Cannaerts, Jan" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   04/01/2018 10:11
> Subject:Re: Intel Chip flaw
> Sent by:IBM Mainframe Discussion List 
>
>
>
> This article:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__
> googleprojectzero.blogspot.be_2018_01_reading-2Dprivileged-
> 2Dmemory-2Dwith-2Dside.html&d=DwIFaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ&m=
> JgfLm1WtVuc3hfiKug2jNzxJ50Cb-S25nq4BySZ38Fs&s=
> z8S5H15LmNsZT976WrrTR3zjzYH6V6IUtFklSLCiQzE&e=
>
>
> Mentions the following:
>
> > Additional exploits for other architectures are also known to exist.
> These
> > include IBM System Z,  POWER8 (Big Endian and Little Endian), and POWER9
> > (Little Endian).
>
> The attacks target flaws in the hardware, in this case related to
> speculative
> execution. But the PoCs I'm seeing so far seem to be meant to leak Linux
> kernel
> memory (leaking passwords/cryptographic keys). The z/Architecture also
> employs speculative execution and branch prediction.
>
> So I'm not sure whether or not there is a working PoC for any Linux
> distribution
> running either Linux native, under z/VM or KVM on System Z, and I cannot
> find
> anything about a PoC for z/OS either.
>
> If the attack can be used against z/OS, I'd wager it could leak
> fetch-protected
> memory that is addressable by the address space in the first place. How
> much
> interesting information there is in fetch-protected storage, I do not
> know.
>
> -
> Jan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Elardus Engelbrecht]

Martin Packer wrote:

>Surely the term "fetch-protected" says it all: In principle you'd fetch 
>protect what you didn't want fetched. :-) Now, I don't know if there is any 
>overhead to fetch protection that might cause you not to fetch protect what 
>should be.

This is the problem just there. 'fetch protection' schemes are bypassed at all 
despite whatever actions the operating systems on a device [PCs, laptops, cloud 
servers, cell phones, virtual machines, etc.] can do.

All those [ hardware / microcode ] algorithms implemented by CPU manufacturers 
were nice to have, since it speeds up loading and execution of instructions + 
memory areas before the actual execution and usage of those memory areas.

Now, those algorithms are exploited. Basically, you load a 'fetch protected' 
address and then use/mis-use 'out of order execution' and 'speculative 
execution' while messing around with the contents of CPU caches. 

Long story, but in short, before you are interrupted because of fetch 
protection, you can dump protected areas to somewhere else.

See these [somewhat technical] papers:

https://meltdownattack.com/meltdown.pdf
https://spectreattack.com/spectre.pdf

Only way to be 100% safe (?), update your systems including Linux systems and 
do a hardware CPU [any device with a CPU] upgrade/replacing...

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Martin Packer]

Surely the term "fetch-protected" says it all: In principle you'd fetch 
protect what you didn't want fetched. :-) Now, I don't know if there is 
any overhead to fetch protection that might cause you not to fetch protect 
what should be.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   "Cannaerts, Jan" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   04/01/2018 10:11
Subject:Re: Intel Chip flaw
Sent by:IBM Mainframe Discussion List 



This article: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__googleprojectzero.blogspot.be_2018_01_reading-2Dprivileged-2Dmemory-2Dwith-2Dside.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ&m=JgfLm1WtVuc3hfiKug2jNzxJ50Cb-S25nq4BySZ38Fs&s=z8S5H15LmNsZT976WrrTR3zjzYH6V6IUtFklSLCiQzE&e=


Mentions the following:

> Additional exploits for other architectures are also known to exist. 
These
> include IBM System Z,  POWER8 (Big Endian and Little Endian), and POWER9
> (Little Endian).

The attacks target flaws in the hardware, in this case related to 
speculative
execution. But the PoCs I'm seeing so far seem to be meant to leak Linux 
kernel
memory (leaking passwords/cryptographic keys). The z/Architecture also
employs speculative execution and branch prediction.

So I'm not sure whether or not there is a working PoC for any Linux 
distribution
running either Linux native, under z/VM or KVM on System Z, and I cannot 
find
anything about a PoC for z/OS either.

If the attack can be used against z/OS, I'd wager it could leak 
fetch-protected
memory that is addressable by the address space in the first place. How 
much
interesting information there is in fetch-protected storage, I do not 
know.

-
Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Cannaerts, Jan]

This article: 
https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html

Mentions the following:

> Additional exploits for other architectures are also known to exist. These
> include IBM System Z,  POWER8 (Big Endian and Little Endian), and POWER9
> (Little Endian).

The attacks target flaws in the hardware, in this case related to speculative
execution. But the PoCs I'm seeing so far seem to be meant to leak Linux kernel
memory (leaking passwords/cryptographic keys). The z/Architecture also
employs speculative execution and branch prediction.

So I'm not sure whether or not there is a working PoC for any Linux distribution
running either Linux native, under z/VM or KVM on System Z, and I cannot find
anything about a PoC for z/OS either.

If the attack can be used against z/OS, I'd wager it could leak fetch-protected
memory that is addressable by the address space in the first place. How much
interesting information there is in fetch-protected storage, I do not know.

-
Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Intel Chip flaw

[Salva Carrasco]

Are zArch CPUs free of these attacks? any IBM info?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Intel Chip flaw

[Edward Finnell]

Ouch.

https://www.pcmag.com/news/358249/intel-chips-have-a-major-design-flaw-and-the-fix-means-slowe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN