Greetings Carey,
Riffing on your theme, exactly how did the malicious code that is
undermining the speculative path of execution in cache, actually get
there?
Another thread or process?
Sincerely,
Flint
On Mon, 15 Jan 2018, Carey Tyler Schug wrote:
Date: Mon, 15 Jan 2018 20:48:20 -0600
From: Carey Tyler Schug <sqrfolk...@comcast.net>
Reply-To: Linux on 390 Port <LINUX-390@VM.MARIST.EDU>
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Spectre and Meltdown stupid question...
In what I read, i didn't see any dependency on multiple cores, if so, it
would be dependent on what was running in the other core, if the kernel
didn't run there, no exposure.e
AFAICS, you try to read something you are not allowed to. speculative
execution does this, but then it gets canceled when it realizes you are not
allowed to. but it is in the cache, so somehow it can later be gotten from
cache. try to do tests on that data, "is it a 3, do a if so, do b if not"
and see if a or b was speculatively executed because one is slower than the
other?
Oh, maybe the multiple cores would give vulnerability to other users' memory,
if it happened to be in your cache? Or their exploit, to run fast, has to be
running on two cores in the same chip, as an implementation issue. Some
examples seemed to imply that. I think it just means with a single core, it
would take longer, maybe much longer.
I don't know I86, but I think there is one address space per task, that
includes all the kernel, hence the vulnerability. You can address all of the
kernel, it takes memory rules to stop you.
But in zVM, the page and segment tables still apply, so even speculative
execution would not have access to nucleus data, or other virtual machines.
As a user, no address in your space corresponds to any part of the nucleus.
speculative execution or not, you cannot give an address that will even try
to read any nucleus memory. In zOS do you have the nucleus in your
page/segment tables, making them vulnerable?
One linux instance, in one virtual machine could have the same vulnerability
as on x86, though. Or not as bad, especially with many cores, since if the
second time you are on a different core, you will have different cache...and
have to start over loading the memory you aren't supposed to have into cache
ONe woould think any exploit would leave tracks (memory violations) that
could be detected and the process stopped before a significant amount of
data was extracted. Shouldn't trying to address restricted memory cause an
interrupt? If not, I would say that was the flaw in the chips.
but I really don't know what I'm talking about, probably everything I said
above is wrong.
--Carey
On 01/15/2018 05:57 PM, Henry Schaffer wrote:
I'm not sure whether I'm providing more of an answer or more of a question
- but ...
My understanding is that this "leakage" of data happens on the chip via
access to cache - certainly on a core, i.e. between two threads running on
the same core. I don't know about two different cores on the same chip - do
they share cache so that this leakage can occur between different cores?
The two threads could be in different virtual machines and so wouldn't be
isolated because they are in different virtual machines *if* they are
running on the same core (or chip, if ....)
If I'm right about it being only via cache - then nothing is new that I can
see regarding memory management.
I'd appreciate feedback.
--henry schaffer
On Mon, Jan 15, 2018 at 6:06 PM, Carey Tyler Schug <sqrfolk...@comcast.net>
wrote:
another stupid question.
This is ONLY for Linux on z, correct? and only within one Linux instance?
If 200 copies of Linux are running under one z/vm, the only risk is within
each of the Linux instances.
Meaning accounting running in Linux #1 is not at risk from anything else
running in any of the other 199 Linux instances? doesn't z/vm, th rough
virtual storage, isolate each Linux from all the others?
if something is running "native" on CM or some other code within a virtual
machine, it is safe from all other virtual machines?
If the above is incorrect, is there an explanation somewhere as to how the
vulnerability works?
--Carey
On 01/15/2018 09:30 AM, Martha McConaghy wrote:
Paul,
The answer is "yes". A MCL for hardware came out last week. I believe it
applies to models z14 down through z114. At least, our z13s, BC12 and
z114
all received it. (We wanted it on as soon as possible.)
In addition, there is a z/VM PTF, though I'm not sure it is out yet. Its
z/VM
6.4 only, so I can't get it until I finish getting my systems upgraded.
I'm
not as worried about z/VM since our users/customers have no direct access
to
it.
The Linux distributions have been our main concern and the patches have
been
coming out slowly. Its my understanding that "meltdown" is not much of a
concern for Z but "spectre" is. (Someone correct me if I'm misstating
anything.) SUSE has some patches out already, expecting more today.
RedHat
does not have theirs out yet. Last I heard, they are expected sometime
next
week. I don't know about any of the other distributions that run on Z.
I
haven't heard that they have any patches out yet.
Martha
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Kindest Regards,
☮ Paul Flint
(802) 479-2360 Home
(802) 595-9365 Cell
/************************************
Based upon email reliability concerns,
please send an acknowledgement in response to this note.
Paul Flint
17 Averill Street
Barre, VT
05641
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
