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