Discussion:
System z & Meltdown/Spectre
(too old to reply)
R.S.
2018-01-09 21:40:12 UTC
Permalink
Raw Message
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 isolation???

(BTW: it's not known the z CPU is vulnerable, the above is only logical
assumtion.)
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sankaranarayanan, Vignesh
2018-01-10 00:13:06 UTC
Permalink
Raw Message
Hi,

If you sign up for the System z Security Portal, the notice pertaining this vuln will be updated with more details over time.
Right now, it has some detail, but we'll surely see more info soon.

- Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of R.S.
Sent: 10 January 2018 03:11
To: IBM-***@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 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 isolation???

(BTW: it's not known the z CPU is vulnerable, the above is only logical
assumtion.)

--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
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
Dana Mitchell
2018-01-10 16:27:54 UTC
Permalink
Raw Message
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
Post by Sankaranarayanan, Vignesh
Hi,
If you sign up for the System z Security Portal, the notice pertaining this vuln will be updated with more details over time.
Right now, it has some detail, but we'll surely see more info soon.
- Vignesh
Mainframe Infrastructure
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sankaranarayanan, Vignesh
2018-01-10 16:40:10 UTC
Permalink
Raw Message
Considering the inefficient exceution path, I wonder how much higher the CPU % will be for z/VM, z/OS, etc.
And more importantly, how it affects 4HRA, and $$$.

If there's a significant CPU hit, maybe shave some % off the top of the bill, after seeing before and after MSU numbers at each customer site?

– Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Dana Mitchell
Sent: 10 January 2018 21:59
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre

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
Post by Sankaranarayanan, Vignesh
Hi,
If you sign up for the System z Security Portal, the notice pertaining this vuln will be updated with more details over time.
Right now, it has some detail, but we'll surely see more info soon.
- Vignesh
Mainframe Infrastructure
----------------------------------------------------------------------
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
Pommier, Rex
2018-01-10 17:30:22 UTC
Permalink
Raw Message
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 longer being big enough is going to really bite.

Rex

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, Vignesh
Sent: Wednesday, January 10, 2018 10:41 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre

Considering the inefficient exceution path, I wonder how much higher the CPU % will be for z/VM, z/OS, etc.
And more importantly, how it affects 4HRA, and $$$.

If there's a significant CPU hit, maybe shave some % off the top of the bill, after seeing before and after MSU numbers at each customer site?

– Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Dana Mitchell
Sent: 10 January 2018 21:59
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre

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
Post by Sankaranarayanan, Vignesh
Hi,
If you sign up for the System z Security Portal, the notice pertaining this vuln will be updated with more details over time.
Right now, it has some detail, but we'll surely see more info soon.
- Vignesh
Mainframe Infrastructure
----------------------------------------------------------------------
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

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-10 17:09:01 UTC
Permalink
Raw Message
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...)
Post by Sankaranarayanan, Vignesh
Considering the inefficient exceution path, I wonder how much higher the CPU % will be for z/VM, z/OS, etc.
And more importantly, how it affects 4HRA, and $$$.
If there's a significant CPU hit, maybe shave some % off the top of the bill, after seeing before and after MSU numbers at each customer site?
– Vignesh
Mainframe Infrastructure
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-01-10 20:43:23 UTC
Permalink
Raw Message
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?
Would/should IBM use dual tables, for machines with or without the patch?
BTW: It's worth to remember chances the vulnerability would really
compromise system security are really small. (IMHO)
--
Radoslaw Skorupka
Lodz, Poland
Post by Dana Mitchell
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...)
Post by Sankaranarayanan, Vignesh
Considering the inefficient exceution path, I wonder how much higher the CPU % will be for z/VM, z/OS, etc.
And more importantly, how it affects 4HRA, and $$$.
If there's a significant CPU hit, maybe shave some % off the top of the bill, after seeing before and after MSU numbers at each customer site?
– Vignesh
Mainframe Infrastructure
======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-01-10 17:50:45 UTC
Permalink
Raw Message
Post by Pommier, Rex
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 longer being big enough is going to really bite.
There's a cynical suspicion that when a vendor sees defect repair as a profit center
it provides a disincentive to quality.

This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."

In fairness, we don't know what IBM plans to do.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pommier, Rex
2018-01-10 19:14:09 UTC
Permalink
Raw Message
Gil,

I don't think this one is necessarily a quality issue. As widespread as the problem is, it appears to me to be more of a huuuge oversight. That said, you are correct in that we don't know what IBM plans to do, or for that matter, even how much of an impact fixing this will be on performance of z/OS. My concern is that since we (as well as probably many of the sites on this board) are bumping against our cap and if we get hit by even a 10% reduction in thruput from this, we're in danger of missing SLAs and other fun TLAs.

Rex

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Wednesday, January 10, 2018 11:52 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre
Post by Pommier, Rex
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 longer being big enough is going to really bite.
There's a cynical suspicion that when a vendor sees defect repair as a profit center
it provides a disincentive to quality.

This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."

In fairness, we don't know what IBM plans to do.

-- gil

----------------------------------------------------------------------
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
Mike Schwab
2018-01-11 02:53:52 UTC
Permalink
Raw Message
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%.
Post by Pommier, Rex
Gil,
I don't think this one is necessarily a quality issue. As widespread as the problem is, it appears to me to be more of a huuuge oversight. That said, you are correct in that we don't know what IBM plans to do, or for that matter, even how much of an impact fixing this will be on performance of z/OS. My concern is that since we (as well as probably many of the sites on this board) are bumping against our cap and if we get hit by even a 10% reduction in thruput from this, we're in danger of missing SLAs and other fun TLAs.
Rex
-----Original Message-----
Sent: Wednesday, January 10, 2018 11:52 AM
Subject: Re: System z & Meltdown/Spectre
Post by Pommier, Rex
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 longer being big enough is going to really bite.
There's a cynical suspicion that when a vendor sees defect repair as a profit center
it provides a disincentive to quality.
This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."
In fairness, we don't know what IBM plans to do.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
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,
--
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
Rugen, Len
2018-01-11 03:32:54 UTC
Permalink
Raw Message
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.


Len Rugen

University of Missouri
Division of Information Technology
Systems & Operations - Metrics & Automation Team
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Mike Schwab <***@GMAIL.COM>
Sent: Wednesday, January 10, 2018 8:55:07 PM
To: IBM-***@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%.
Post by Pommier, Rex
Gil,
I don't think this one is necessarily a quality issue. As widespread as the problem is, it appears to me to be more of a huuuge oversight. That said, you are correct in that we don't know what IBM plans to do, or for that matter, even how much of an impact fixing this will be on performance of z/OS. My concern is that since we (as well as probably many of the sites on this board) are bumping against our cap and if we get hit by even a 10% reduction in thruput from this, we're in danger of missing SLAs and other fun TLAs.
Rex
-----Original Message-----
Sent: Wednesday, January 10, 2018 11:52 AM
Subject: Re: System z & Meltdown/Spectre
Post by Pommier, Rex
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 longer being big enough is going to really bite.
There's a cynical suspicion that when a vendor sees defect repair as a profit center
it provides a disincentive to quality.
This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."
In fairness, we don't know what IBM plans to do.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
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,
--
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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2018-01-11 04:32:10 UTC
Permalink
Raw Message
Unless you bought full speed processor, yes there is room for
improvement. But the waits for data count toward your reduce CPU
costs. I.E. a full speed CPU sees delays due to waiting, versus a
slower processor counts those delays toward the reduced CPU speed.
Post by Rugen, Len
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.
Len Rugen
University of Missouri
Division of Information Technology
Systems & Operations - Metrics & Automation Team
________________________________
Sent: Wednesday, January 10, 2018 8:55:07 PM
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%.
Post by Pommier, Rex
Gil,
I don't think this one is necessarily a quality issue. As widespread as the problem is, it appears to me to be more of a huuuge oversight. That said, you are correct in that we don't know what IBM plans to do, or for that matter, even how much of an impact fixing this will be on performance of z/OS. My concern is that since we (as well as probably many of the sites on this board) are bumping against our cap and if we get hit by even a 10% reduction in thruput from this, we're in danger of missing SLAs and other fun TLAs.
Rex
-----Original Message-----
Sent: Wednesday, January 10, 2018 11:52 AM
Subject: Re: System z & Meltdown/Spectre
Post by Pommier, Rex
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 longer being big enough is going to really bite.
There's a cynical suspicion that when a vendor sees defect repair as a profit center
it provides a disincentive to quality.
This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."
In fairness, we don't know what IBM plans to do.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
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,
--
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,
----------------------------------------------------------------------
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
R.S.
2018-01-11 12:31:08 UTC
Permalink
Raw Message
If you have full speed processor then you can have ...more processors.
Let's not talk about models with all 170 processors activated and in use ;-)

However Len suggested the full speed processor can have some hidden
capacity. Well, maybe it has, but there is no evidence for such approach.
--
Radoslaw Skorupka
Lodz, Poland
Post by Mike Schwab
Unless you bought full speed processor, yes there is room for
improvement. But the waits for data count toward your reduce CPU
costs. I.E. a full speed CPU sees delays due to waiting, versus a
slower processor counts those delays toward the reduced CPU speed.
Post by Rugen, Len
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.
Len Rugen
University of Missouri
Division of Information Technology
Systems & Operations - Metrics & Automation Team
________________________________
Sent: Wednesday, January 10, 2018 8:55:07 PM
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%.
Post by Pommier, Rex
Gil,
I don't think this one is necessarily a quality issue. As widespread as the problem is, it appears to me to be more of a huuuge oversight. That said, you are correct in that we don't know what IBM plans to do, or for that matter, even how much of an impact fixing this will be on performance of z/OS. My concern is that since we (as well as probably many of the sites on this board) are bumping against our cap and if we get hit by even a 10% reduction in thruput from this, we're in danger of missing SLAs and other fun TLAs.
Rex
-----Original Message-----
Sent: Wednesday, January 10, 2018 11:52 AM
Subject: Re: System z & Meltdown/Spectre
Post by Pommier, Rex
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 longer being big enough is going to really bite.
There's a cynical suspicion that when a vendor sees defect repair as a profit center
it provides a disincentive to quality.
This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."
In fairness, we don't know what IBM plans to do.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
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,
--
======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-01-10 21:24:45 UTC
Permalink
Raw Message
Post by R.S.
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 reloaded into
cache. In a real system the amount of cache activity is too high for
the technique to be reliable. And the attacking task would use a lot
of CPU, making it unlikely that WLM would allow it to complete its
work without being interrupted frequently.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Parwez Hamid
2018-01-11 08:59:17 UTC
Permalink
Raw Message
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 (for the high end systems) and A01 to Z01 (for the mid range systems)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dana Mitchell
2018-01-11 13:34:05 UTC
Permalink
Raw Message
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 show similar behaivor.

Dana
Post by Rugen, Len
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.
Len Rugen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Scott Chapman
2018-01-11 14:15:58 UTC
Permalink
Raw Message
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 assuming of course that it's even possible. But because it seems that there are some patches coming to Linux on the platform, it seems like there's at least some possibility that recent hardware is at least somewhat susceptible. I suspect (but don't know) that the impacts on z, and z/OS in particular, are not as catastrophically bad as some other platforms.

Having said all that, if there is a chance of it being exploited, it will have to be mitigated. The question comes from how much of an impact that mitigation is going to have and whether it's made optional or not. (Some of the Linux mitigations can be selectively disabled.) If it's optional, then it comes down to a risk assessment, and it's going to take much more information before sites can make a choice. If it's not optional (or if the risk assessment indicates many sites need to enable the mitigation) and if the impact is more than a small single digit impact for typical workloads, then... this will get really "interesting".

I've personally experienced that "interesting" on our main AWS processing server, which was using the older PV virtualization. The impact was significant and definitely pushed us over the edge in dramatic fashion. Fortunately, moving to current-generation HVM instances has more than offset the performance impacts that we were seeing. Unfortunately that move was more than a shutdown and start back up and ran into more "interesting" AWS issues/limitations. It's been an "interesting" week.

Hopefully this all will be less painful on z/OS.

Scott Chapman
Post by Tom Marchant
Post by R.S.
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 reloaded into
cache. In a real system the amount of cache activity is too high for
the technique to be reliable. And the attacking task would use a lot
of CPU, making it unlikely that WLM would allow it to complete its
work without being interrupted frequently.
--
Tom Marchant
----------------------------------------------------------------------
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
Edward Finnell
2018-01-11 18:44:00 UTC
Permalink
Raw Message
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:19:13 AM Central Standard Time, ***@EPSTRATEGIES.COM writes:

 
Having said all that, if there is a chance of it being exploited, it will have to be mitigated. The question comes from how much of an impact that mitigation is going to have and whether it's made optional or not. (Some of the Linux mitigations can be selectively disabled.) If it's optional, then it comes down to a risk assessment, and it's going to take much more information before sites can make a choice. If it's not optional (or if the risk assessment indicates many sites need to enable the mitigation) and if the impact is more than a small single digit impact for typical workloads, then... this will get really "interesting".

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2018-01-11 22:02:23 UTC
Permalink
Raw Message
Post by Tom Marchant
Post by R.S.
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 reloaded into
cache. In a real system the amount of cache activity is too high for
the technique to be reliable. And the attacking task would use a lot
of CPU, making it unlikely that WLM would allow it to complete its
work without being interrupted frequently.
Assuming, of course, that the attack occurs on a heavily-used production system. On a more lightly-used system, perhaps a test system with access to shared data or with a shared security database or shared ICSF data such that credentials "stolen" on one system could be used on another, it might be more successful.

That would come down to other factors of data segregation and security, and require additional analysis.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-01-12 00:36:54 UTC
Permalink
Raw Message
Post by Walt Farrell
Post by Tom Marchant
Post by R.S.
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 reloaded into
cache. In a real system the amount of cache activity is too high for
the technique to be reliable. And the attacking task would use a lot
of CPU, making it unlikely that WLM would allow it to complete its
work without being interrupted frequently.
Assuming, of course, that the attack occurs on a heavily-used production system. On a more lightly-used system, perhaps a test system with access to shared data or with a shared security database or shared ICSF data such that credentials "stolen" on one system could be used on another, it might be more successful.
That would come down to other factors of data segregation and security, and require additional analysis.
IMHO shared sesnsitive data like RACF db or ICSF PKDS is not an issue -
one should not share such information between production and test.
What's much more interesting is:
Is it possible to perform attack from sandbox system (LPAR) to access
data from production system working in another LPAR on the same CPC?
Let's assume all LPARs are lightly used and other assumption helping
attacker to perform the attack...

Regards
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...