On 2018-01-26 14:50, Jesse 1 Robinson wrote:
My first reaction to this suggestion was "as if". Then I remembered from long ago an
actual IBM recommendation that TSO 'performance expectation' be kept in check by deliberately
setting response to some defined level like (say) three seconds. The id
o: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: System z & Meltdown/Spectre
I wonder if the microcode has a little "detuning" so that if they ever have to
make patches that would slow down the system, they can remove a little of the
detuning to get back to base performance
W dniu 2018-01-11 o 23:03, Walt Farrell pisze:
On Wed, 10 Jan 2018 15:26:04 -0600, Tom Marchant
wrote:
On Wed, 10 Jan 2018 21:44:29 +0100, R.S. wrote:
BTW: It's worth to remember chances the vulnerability would really
compromise system security are really small. (IMHO)
I agree. Especially
On Wed, 10 Jan 2018 15:26:04 -0600, Tom Marchant
wrote:
>On Wed, 10 Jan 2018 21:44:29 +0100, R.S. wrote:
>
>>BTW: It's worth to remember chances the vulnerability would really
>>compromise system security are really small. (IMHO)
>
>I agree. Especially since the method of exploiting it involves
Yeah, we put performance bonds on everything from pencil sharpeners to
bulldozers. In the past we were able to work out agreements with vendors. Some
scale, some fail some just pass it on. In a tort friendly state we usually at
least cover the cost of conversion.
In a message dated 1/11/2018 8
I agree: from a practical perspective, unauthorized user code running on on a
typical z/OS system has many more practical barriers to being able to use the
side channel communication methods involved in Meltdown/Spectre. However,
"difficult" and "unlikely" doesn't mean "impossible". That's assum
It sounds like for z/VM at least, that any performance impact will be dependent
on the workload and "enablement settings".And application of these MCLs
without applying operating system software PTFs will not have an impact on
system performance. I would have to assume the z/OS PTFs will s
LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre
Yep. I know my site didn't purchase upgrades until running at 100%
all weekday long would slow down batch runs by 4X elapsed time
compared to 90%.
On Wed, Jan 10, 2018 at 1:15 PM, Pommier, Rex wrote:
Gil,
I don't think th
You talk about 'speeds'. Just to make sure there is no confusion between
'speed' and 'capacity'. In any generation of Z system, the processor cycle
(speed) time is always the same. Taking a single CP system as an example. what
you have is different CAPACITY SETTINGs e.g. 401 or 501 or 601 or 701
Missouri
> Division of Information Technology
> Systems & Operations - Metrics & Automation Team
>
> From: IBM Mainframe Discussion List on behalf of
> Mike Schwab
> Sent: Wednesday, January 10, 2018 8:55:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
mp; Operations - Metrics & Automation Team
From: IBM Mainframe Discussion List on behalf of
Mike Schwab
Sent: Wednesday, January 10, 2018 8:55:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre
Yep. I know my site didn't purchas
ssion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, January 10, 2018 11:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: System z & Meltdown/Spectre
>
> On Wed, 10 Jan 2018 17:31:37 +, Pommier, Rex wrote:
>
>>And w
On Wed, 10 Jan 2018 21:44:29 +0100, R.S. wrote:
>BTW: It's worth to remember chances the vulnerability would really
>compromise system security are really small. (IMHO)
I agree. Especially since the method of exploiting it involves flushing
cache and testing to see what memory location was reloa
1. Older generations (z10, z9...) are not affected.
2. Let's assume one uses EC12 which is affected. Let's assume after the
vulnerability is fixed the capacity went down up to 10%.
Or 20%. 20% is a lot. Now, what about customer who decided to NOT apply
the patch just to have better performance?
: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, January 10, 2018 11:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre
On Wed, 10 Jan 2018 17:31:37 +, Pommier, Rex wrote:
>And what does "a si
On Wed, 10 Jan 2018 17:31:37 +, Pommier, Rex wrote:
>And what does "a significant CPU hit" mean for those of us who's 4HRA is
>already at the top of our machine's capacity? That's where my concern is.
>Yeah, the money for increasing MSUs is gonna stink, but missing SLAs due to
>the box no
oing to really bite.
Rex
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Sankaranarayanan, Vignesh
Sent: Wednesday, January 10, 2018 10:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre
Considering the ineffic
If it's a big enough hit, perhaps IBM would redo LSPR tests and adjust tables
accordingly. They probably wouldn't re-test anything older than the current
generation of machines on the floor, but they could apply the adjustments to
previous generations (if so inclined...)
On Wed, 10 Jan 2018
each customer site?
– Vignesh
Mainframe Infrastructure
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Dana Mitchell
Sent: 10 January 2018 21:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre
IBM Security notifi
IBM Security notification SN-2018-001 was updated yesterday with some Linux and
z/VM info. Further mitigation details for z/OS will be released as they become
available.
Dana
On Wed, 10 Jan 2018 00:14:10 +, Sankaranarayanan, Vignesh
wrote:
>Hi,
>
>If you sign up for the System z Securit
ssion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of R.S.
Sent: 10 January 2018 03:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: System z & Meltdown/Spectre
IBM is very unclear here.
Assuming the z processor is vulnerable - how wide the vulnerability is?
Let's assume one has 4 LPARs, and one
IBM is very unclear here.
Assuming the z processor is vulnerable - how wide the vulnerability is?
Let's assume one has 4 LPARs, and one is Linux with some poorly
controlled application code - Can such code affect security of other
LPARs systems?
In simple words: what about FIPS-certified LPAR
22 matches
Mail list logo
