Discussion:
Intel Chip flaw
Add Reply
Edward Finnell
2018-01-03 20:46:57 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Salva Carrasco
2018-01-03 21:20:58 UTC
Reply
Permalink
Raw Message
Are zArch CPUs free of these attacks? any IBM info?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Cannaerts, Jan
2018-01-04 10:10:06 UTC
Reply
Permalink
Raw Message
This article: https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Martin Packer
2018-01-04 10:34:10 UTC
Reply
Permalink
Raw Message
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: ***@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" <***@SOCMUT.BE>
To: IBM-***@LISTSERV.UA.EDU
Date: 04/01/2018 10:11
Subject: Re: Intel Chip flaw
Sent by: IBM Mainframe Discussion List <IBM-***@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=
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 ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-01-04 13:06:28 UTC
Reply
Permalink
Raw Message
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.
Post by 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
Twitter / Facebook IDs: MartinPacker
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
Date: 04/01/2018 10:11
Subject: Re: Intel Chip flaw
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=
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,
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOPT1
2018-01-04 13:18:31 UTC
Reply
Permalink
Raw Message
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-----
Behalf Of John McKown
Sent: 04 January, 2018 14:08
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.
Post by Martin Packer
Surely the term "fetch-protected" says it all: In principle you'd
fetch
Post by Martin Packer
protect what you didn't want fetched. :-) Now, I don't know if there
is
Post by Martin Packer
any overhead to fetch protection that might cause you not to fetch
protect
Post by Martin Packer
what should be.
Cheers, Martin
Martin Packer
zChampion, Systems Investigator & Performance Troubleshooter, IBM
+44-7802-245-584
Twitter / Facebook IDs: MartinPacker
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/
or
Post by Martin Packer
https://itunes.apple.com/gb/podcast/mainframe-performance-
topics/id1127943573?mt=2
https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
Post by Martin Packer
Date: 04/01/2018 10:11
Subject: Re: Intel Chip flaw
Sent by: IBM Mainframe Discussion List <IBM-
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=
Additional exploits for other architectures are also known to exist.
These
include IBM System Z, POWER8 (Big Endian and Little Endian), and
POWER9
Post by Martin Packer
(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
Post by Martin Packer
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
Post by Martin Packer
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
Post by Martin Packer
much
interesting information there is in fetch-protected storage, I do not know.
-
Jan
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
IBM United Kingdom Limited - Registered in England and Wales with
number
Post by Martin Packer
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Post by Martin Packer
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
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,
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Finnell
2018-01-04 18:55:34 UTC
Reply
Permalink
Raw Message
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, ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Brennan
2018-01-04 20:16:24 UTC
Reply
Permalink
Raw Message
... 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Finnell
2018-01-05 11:04:02 UTC
Reply
Permalink
Raw Message
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, ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-01-04 16:42:23 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On
Behalf Of Martin Packer
Sent: Thursday, January 4, 2018 2:35 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Brennan
2018-01-04 16:01:36 UTC
Reply
Permalink
Raw Message
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.
Post by Cannaerts, Jan
This article: https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-01-04 16:39:41 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Cannaerts, Jan
Sent: Thursday, January 4, 2018 2:11 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw

This article: https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-01-04 11:05:46 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Randy
2018-01-04 16:27:27 UTC
Reply
Permalink
Raw Message
I assume the HMCs and Support Elements both run on Intel chips. Wouldn't they be vulnerable?
Tom Marchant
2018-01-04 16:29:42 UTC
Reply
Permalink
Raw Message
Post by Cannaerts, Jan
This article: https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
David L. Craig
2018-01-04 17:38:31 UTC
Reply
Permalink
Raw Message
Post by Tom Marchant
Post by Cannaerts, Jan
This article: https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html
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=7016000000127NJAAY
--
<not cent from sell>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Raja Mohan
2018-01-04 17:39:50 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2018-01-04 18:01:55 UTC
Reply
Permalink
Raw Message
Post by 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
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-01-04 18:25:10 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Raja Mohan
Sent: Thursday, January 4, 2018 9:41 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-01-04 18:43:48 UTC
Reply
Permalink
Raw Message
Post by 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.
​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.
Post by Charles Mills
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dana Mitchell
2018-01-04 20:24:33 UTC
Reply
Permalink
Raw Message
How can that possibly pass PCI?
Post by Tom Brennan
... 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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pommier, Rex
2018-01-04 21:24:17 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Dana Mitchell
Sent: Thursday, January 04, 2018 2:26 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw

How can that possibly pass PCI?
Post by Tom Brennan
... 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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dana Mitchell
2018-01-04 21:35:48 UTC
Reply
Permalink
Raw Message
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
Post by 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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dana Mitchell
2018-01-04 22:01:46 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
David L. Craig
2018-01-04 22:04:52 UTC
Reply
Permalink
Raw Message
Post by Dana Mitchell
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.
--
<not cent from sell>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-01-04 22:31:00 UTC
Reply
Permalink
Raw Message
You don't think like an auditor LOL.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of David L. Craig
Sent: Thursday, January 4, 2018 2:06 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw
Post by Dana Mitchell
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
David L. Craig
2018-01-04 23:18:05 UTC
Reply
Permalink
Raw Message
Post by Charles Mills
Post by Charles Mills
Post by Dana Mitchell
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".
--
<not cent from sell>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Phil Smith
2018-01-04 22:32:34 UTC
Reply
Permalink
Raw Message
<snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Adam Johanson
2018-01-04 22:35:05 UTC
Reply
Permalink
Raw Message
John, you mentioned:

<quote>
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".
</quote>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2018-01-04 22:36:59 UTC
Reply
Permalink
Raw Message
1.19?
Post by Adam Johanson
<quote>
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".
</quote>
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Adam Johanson
2018-01-04 22:37:43 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2018-01-06 09:14:52 UTC
Reply
Permalink
Raw Message
Post by Adam Johanson
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? <g>


--
Peter Hunkeler



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Finnell
2018-01-06 09:30:12 UTC
Reply
Permalink
Raw Message
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, ***@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? <g>



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-01-05 01:05:33 UTC
Reply
Permalink
Raw Message
Post by Elardus Engelbrecht
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sankaranarayanan, Vignesh
2018-01-05 04:06:08 UTC
Reply
Permalink
Raw Message
Got an acknowledgement post from syszsec today.

– Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: 05 January 2018 06:37
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw
Post by Elardus Engelbrecht
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 ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-01-05 21:05:54 UTC
Reply
Permalink
Raw Message
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 <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Thursday, January 4, 2018 8:06 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Intel Chip flaw
Post by Elardus Engelbrecht
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Cannaerts, Jan
2018-01-05 09:09:04 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2018-01-05 09:20:52 UTC
Reply
Permalink
Raw Message
Post by Cannaerts, Jan
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-01-05 09:47:35 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Cannaerts, Jan
2018-01-05 09:52:10 UTC
Reply
Permalink
Raw Message
Post by David Crayford
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2018-01-05 12:08:09 UTC
Reply
Permalink
Raw Message
Post by Cannaerts, Jan
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mark Jacobs - Listserv
2018-01-05 13:12:18 UTC
Reply
Permalink
Raw Message
The IBM Security/Integrity portal has the information you're seeking.

Mark Jacobs
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,
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
January 5, 2018 at 4:53 AM
Post by David Crayford
Example code is already out there
https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6
<https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6>.
I
Post by David Crayford
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,
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
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Todd Arnold
2018-01-05 13:47:53 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Finnell
2018-01-05 18:00:38 UTC
Reply
Permalink
Raw Message
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, ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Kittell, Christopher J
2018-01-05 13:48:39 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-01-06 22:12:15 UTC
Reply
Permalink
Raw Message
Post by Mike Schwab
Post by 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
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
don isenstadt
2018-01-07 17:44:40 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Brennan
2018-01-07 21:59:51 UTC
Reply
Permalink
Raw Message
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.
Post by 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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2018-01-07 22:17:51 UTC
Reply
Permalink
Raw Message
It all was tried on the Strech mainframe in the 1950s, late S/370
processors + 1980+, and Intel since the Pentiums.
Post by 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.
Post by 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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-01-07 23:35:42 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Tom Brennan
Sent: Sunday, January 7, 2018 2:01 PM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...