Hi, I was just wondering about what you were referring to. Sorry, I did not really intend to get into this, as I am hardly an expert. I have read a lot about Spectre and Meltdown, but really nothing much as related to IBM. Regretfully I no longer have access to that hardware/software, and just hang out here as I like to know what is happening. Meltdown and Spectre appear to me to be different classes of problems. My understanding is this... Meltdown allows access across permission boundaries as set by the processor (that is, the out of order instructions leave values in cache that can be directly exploited that came from different security levels ... the process did not restrict the invalid memory access when loading it into cache). Spectre allows access within a boundary that is trying to be protected by software (think java container for example). With Meltdown, you can more or less directly access the memory. While Spectre (at least all of the examples that I have seen so far) you need to be a bit trickier about it and determine the values via cache times vs memory accesses. If this is the limitation, it seems like preventing the cache from being cleared would seem to take care of it (for Spectre). I would expect cache to get cleared by the OS (switching between address spaces), but the exploits I saw required the cache being cleared by the user program (to determine if the memory goes into cache). I have not tried any exploits myself, so I am unsure if that is a restriction. So most processors do not allow Meltdown, but most do allow Spectre (those that do speculative execution, which includes most high performance ones). I am unsure how all that relates to IBM Processors.
Thanks, Steven Peckham. -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Dan Skwire Sent: Tuesday, January 16, 2018 12:26 PM To: [email protected] Subject: Re: Spectre and Meltdown stupid question... Email sent from outside of CMS/CE. Use caution before clicking links/attachments. Hello Steven, I’m not sure of what you are asking. I have found no such op-code for CLEAR CACHE, in x86 or System/z. Maybe be I’m searching incorrectly. But these cache problems occur within the execution of op-codes, “under the covers”, not addressable by program control directly. It is part of the internal pipelining (old term) of processor chips. Whether a processor chip does or does not perform “speculative execution” is not under program control AFAIK. And similarly whether or not it discards prefetched cache entries is similarly hardwired/microcoded in the chip, far away from direct software control, AFAIK. There are Windows Software mitigations for some variations of the x86 problems... It has been pointed out that official IBM responses and/or actions are found within the designated sections of the website. And mentioned just earlier, that ACCURATE tutorial information for this complex situation couldn’t arrive fast enough. Dan Dan Skwire author: "First Fault Software Problem Solving" http://www.linkedin.com/in/danskwire 4800 Country Meadows Boulevard Sarasota,FL 34235 h: 941-378-2383 c: 941-400-7632 [email protected] Sent from my iPhone > On Jan 16, 2018, at 10:11 AM, STEVEN C. PECKHAM > <[email protected]> wrote: > > Hi, > > So Basically what you are suggesting is that the clear cache instruction > should not actually do anything (just treated as a NOOP) unless executed at > OS level? > Which should stop the current set of exploits that rely on the cache hit > times (unless they have full access, in which case you can just read the > memory anyway)... or actually clearing the potential cache loads themselves? > > Just Curious... > > Thanks, > Steven Peckham. > > > > -----Original Message----- > From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Dan > Skwire > Sent: Tuesday, January 16, 2018 8:44 AM > To: [email protected] > Subject: Re: Spectre and Meltdown stupid question... > > Email sent from outside of CMS/CE. Use caution before clicking > links/attachments. > > > Paul, there has been no malicious code found in production in the “real > world”, just in test cases created to exploit the weakness, via a > demonstration. > > But the weakness in both Meltdown AND Spectre is that processor cache is > loaded and not cleared when a “speculative execution” code path is performed. > The “potential” code path is executed and register changes, planned storage > alterations, etc all are backed out when it is decided that that action is > not the correct path. EVERYTHING is backed out, EXCEPT cache that got loaded. > > Both Meltdown and Spectra use various techniques to either interrogate or > read those cache entries. And they force data to be loaded into the cache > that normal permissions would have prevented. > > It is a “cache” business. “Monkey business”. > > Who ever thought that those wasted cache loads would ever be interrogated? > Why bother to waste logic to clear those cache entries? > Well... > > So, it has been found that Intel, ARM, and other chips have these cache > operation failings. These are a result of lack of cleanup regarding the path > in “speculative execution” on those chips. System/z processors also use > “speculative execution”. Cache cleanups? Not publicly posted AFAIK. > > I welcome comments. I have read several papers and have understood some... > But I think it’s all about “cache” and the many ways its lack of cleanup can > be exploited by attackers, in actually quite a variety of ways. > > Dan > > Dan Skwire > author: "First Fault Software Problem Solving" > http://www.linkedin.com/in/danskwire > 4800 Country Meadows Boulevard > Sarasota,FL 34235 > h: 941-378-2383 c: 941-400-7632 > [email protected] > > Sent from my iPhone > >> On Jan 16, 2018, at 7:00 AM, Paul Flint <[email protected]> wrote: >> >> 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 <[email protected]> >>> Reply-To: Linux on 390 Port <[email protected]> >>> To: [email protected] >>> 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 <[email protected]> >>>> 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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/
