Re: Removal of transactional execution facility
Maybe Dan Greiner can comment on why IBM went to the trouble to introduce this powerful facility and then pull it? ISVs who implemented code using the transactional execution facility might feel kinda "had" now... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Wed, Apr 6, 2022 at 4:17 PM Ngan, Robert (DXC Luxoft) < robert.n...@dxc.com> wrote: > In the Statement of general direction in the z16 announcement at: > > > https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/1/897/ENUS122-001/index.html > > It says IBM will remove support for the transactional execution facility, > I guess there's no point in attempting to exploit this now. > > Robert Ngan > DXC Luxoft >
Re: Removal of transactional execution facility
The dual path requirement put me off doing anything with it for a long time. I thought using it to follow suspect pointer chains instead of using ESPIE/ESTAE would be worth dual pathing the ESPIE/ESTAE code, but that is now moot. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mike Shaw Sent: Wednesday, April 6, 2022 15:23 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Removal of transactional execution facility Maybe Dan Greiner can comment on why IBM went to the trouble to introduce this powerful facility and then pull it? ISVs who implemented code using the transactional execution facility might feel kinda "had" now... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Wed, Apr 6, 2022 at 4:17 PM Ngan, Robert (DXC Luxoft) < robert.n...@dxc.com> wrote: > In the Statement of general direction in the z16 announcement at: > > > https://clicktime.symantec.com/3EajRQyLQEC62msLUyNtDVZ6xn?u=https%3A%2 > F%2Fwww.ibm.com%2Fcommon%2Fssi%2FShowDoc.wss%3FdocURL%3D%2Fcommon%2Fss > i%2Frep_ca%2F1%2F897%2FENUS122-001%2Findex.html > > It says IBM will remove support for the transactional execution > facility, I guess there's no point in attempting to exploit this now. > > Robert Ngan > DXC Luxoft >
Re: Removal of transactional execution facility
I was as surprised – no, make that shocked – to see that IBM announced the removal of transactional-execution (TX) and constrained-transactional-execution (CTX) facilities in some future Z system. During the development of the facility, it showed significant (incredible!) performance benefits in lock elision; it was also touted by the Java development team for its speculative-execution characteristics. Having been retired for over four years now, I cannot speak to the rationale (or irrationale) for planning on the facilities' removal. One might speculate that the minimal usage of the facilities did not justify the ongoing complexity of their implementation (TX is REALLY complex). As with any new architectural feature, it takes quite a while before many ISVs and customers exploit it. Having to dual-path one's code to account for the presence or absence of such a facility only prolongs the delay in exploitation. Consider how long it takes for an OS's level-set to catch up with the ever-evolving architecture. But if TX was such a hot feature, why wasn't its exploitation by IBM's own software sufficient to justify the obvious benefits that it provided? As the announcement letter said, "In some future IBM Z hardware system family, the transactional execution and constrained transactional execution facility will no longer be supported." Perhaps this ambiguity opens the possibility to a change of heart on IBM's part if enough customers and ISVs protest loudly enough ... but I doubt it. As to Mr. Shaw's comment about "feeling kinda 'had' now" ... yeah, that's a polite way to put it.
Re: Removal of transactional execution facility
Hmmm, you mention "speculative execution". Maybe that make it vulnerable to meltdown/spectre type attacks. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dan Greiner Sent: Wednesday, April 6, 2022 17:47 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Removal of transactional execution facility I was as surprised – no, make that shocked – to see that IBM announced the removal of transactional-execution (TX) and constrained-transactional-execution (CTX) facilities in some future Z system. During the development of the facility, it showed significant (incredible!) performance benefits in lock elision; it was also touted by the Java development team for its speculative-execution characteristics. Having been retired for over four years now, I cannot speak to the rationale (or irrationale) for planning on the facilities' removal. One might speculate that the minimal usage of the facilities did not justify the ongoing complexity of their implementation (TX is REALLY complex). As with any new architectural feature, it takes quite a while before many ISVs and customers exploit it. Having to dual-path one's code to account for the presence or absence of such a facility only prolongs the delay in exploitation. Consider how long it takes for an OS's level-set to catch up with the ever-evolving architecture. But if TX was such a hot feature, why wasn't its exploitation by IBM's own software sufficient to justify the obvious benefits that it provided? As the announcement letter said, "In some future IBM Z hardware system family, the transactional execution and constrained transactional execution facility will no longer be supported." Perhaps this ambiguity opens the possibility to a change of heart on IBM's part if enough customers and ISVs protest loudly enough ... but I doubt it. As to Mr. Shaw's comment about "feeling kinda 'had' now" ... yeah, that's a polite way to put it.
Re: Removal of transactional execution facility
I believe any speculative execution, including starting to process both paths of a conditional branch in advance, is open to spectre if you don't clean up all internal traces of the path not taken before returning control to the next instruction. It may be that it's messier or more time-consuming to clean up after transactional execution because there could be a lot more speculative execution before it fails. On 2022-04-06 7:46 p.m., Ngan, Robert (DXC Luxoft) wrote: Hmmm, you mention "speculative execution". Maybe that make it vulnerable to meltdown/spectre type attacks. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dan Greiner Sent: Wednesday, April 6, 2022 17:47 To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Removal of transactional execution facility I was as surprised – no, make that shocked – to see that IBM announced the removal of transactional-execution (TX) and constrained-transactional-execution (CTX) facilities in some future Z system. During the development of the facility, it showed significant (incredible!) performance benefits in lock elision; it was also touted by the Java development team for its speculative-execution characteristics. Having been retired for over four years now, I cannot speak to the rationale (or irrationale) for planning on the facilities' removal. One might speculate that the minimal usage of the facilities did not justify the ongoing complexity of their implementation (TX is REALLY complex). As with any new architectural feature, it takes quite a while before many ISVs and customers exploit it. Having to dual-path one's code to account for the presence or absence of such a facility only prolongs the delay in exploitation. Consider how long it takes for an OS's level-set to catch up with the ever-evolving architecture. But if TX was such a hot feature, why wasn't its exploitation by IBM's own software sufficient to justify the obvious benefits that it provided? As the announcement letter said, "In some future IBM Z hardware system family, the transactional execution and constrained transactional execution facility will no longer be supported." Perhaps this ambiguity opens the possibility to a change of heart on IBM's part if enough customers and ISVs protest loudly enough ... but I doubt it. As to Mr. Shaw's comment about "feeling kinda 'had' now" ... yeah, that's a polite way to put it.
Re: Removal of transactional execution facility
On Wed, 6 Apr 2022 at 19:47, Ngan, Robert (DXC Luxoft) wrote: > > Hmmm, you mention "speculative execution". Maybe that make it vulnerable to > meltdown/spectre type attacks. Intel has had a similar scheme (TSX) for around 10 years. Any signs of their dropping it for lack of use...? Certainly they've encountered some problems related to its interaction with speculative execution, and each time their response seems to have been to disable TSX via microcode on all or certain processors. Wikipedia has some info on Intel's implementation at https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions It appears that, like the zArch implementation, Intel's requires programs to provide an alternative path around TSX. Tony H.
Re: Removal of transactional execution facility
On 4/7/2022 8:07 AM, Tony Harminc wrote: It appears that, like the zArch implementation, Intel's requires programs to provide an alternative path around TSX. z/Architecture does *not* require an alternative path around TBEGINC/TEND. The only reason a developer might provide an alternate path for TBEGINC/TEND is to fully support all of the environments in which z/OS 2.3 runs. If your software currently supports only z/OS 2.4 and higher, no alternate path is needed. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Removal of transactional execution facility
On Apr 7, 2022, at 09:57:35, Ed Jaffe wrote: > > On 4/7/2022 8:07 AM, Tony Harminc wrote: >> >> It appears that, like the zArch implementation, Intel's requires >> programs to provide an alternative path around TSX. > > z/Architecture does *not* require an alternative path around TBEGINC/TEND. > How, then, does z/Architecture defend against such as Spectre? Does it balance paths so all exhibit the worst-case timing? Vague recollections from unreliable sources: o Spectre on an unprotected system reads fetch-protected storage At about 1000 bits/second. o Javascript combats Spectre by fuzzing the real time clock. O [Some] kernels combat Spectre by relocating sensitive buffers frequently and randomly. -- gil
Re: Removal of transactional execution facility
On 4/7/2022 9:16 AM, Paul Gilmartin wrote: On Apr 7, 2022, at 09:57:35, Ed Jaffe wrote: z/Architecture does *not* require an alternative path around TBEGINC/TEND. How, then, does z/Architecture defend against such as Spectre? Does it balance paths so all exhibit the worst-case timing? Speculative execution is constantly being done for all instruction paths, not just those inside TBEGINC/TEND. How IBM Z defends against spectre has never been disclosed. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Removal of transactional execution facility
If you research general discussion about how Spectre worked, it appears it was dependent on data being brought into cache or not from the path not taken. Timing how long it took to access the data indirectly a second time could reveal something about the data value. On 2022-04-07 12:30 p.m., Ed Jaffe wrote: On 4/7/2022 9:16 AM, Paul Gilmartin wrote: On Apr 7, 2022, at 09:57:35, Ed Jaffe wrote: z/Architecture does *not* require an alternative path around TBEGINC/TEND. How, then, does z/Architecture defend against such as Spectre? Does it balance paths so all exhibit the worst-case timing? Speculative execution is constantly being done for all instruction paths, not just those inside TBEGINC/TEND. How IBM Z defends against spectre has never been disclosed. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Removal of transactional execution facility
On Apr 7, 2022, at 10:40:36, Gary Weinhold wrote: > > If you research general discussion about how Spectre worked, it appears > it was dependent on data being brought into cache or not from the path > not taken. Timing how long it took to access the data indirectly a > second time could reveal something about the data value. > > On 2022-04-07 12:30 p.m., Ed Jaffe wrote: >> >> >> How IBM Z defends against spectre has never been disclosed. >> Security by Obscurity. -- gil
Re: Removal of transactional execution facility
I was at a meeting IBM had with several ISVs at which removal of TX and CTX was discussed. The consensus in the room seemed to be that no one particularly cared about TX, but many cared rather strongly about CTX! It turned out that several ISVs were using CTX and that they realized significant benefit from doing so. Apparently, there was more usage than I think IBM expected. So I don't think it's accurate to think that there was "minimal usage". I am hopeful that IBM will reconsider in light of this input. Note, "dual path'ing" your code applies to TX, not to CTX. David Cole President, ColeSoft Marketing dbc...@gmail.com (personal) dbc...@colesoft.com (business) 540-456-6518 (cell) At 4/6/2022 06:46 PM, Dan Greiner wrote: I was as surprised no, make that shocked to see that IBM announced the removal of transactional-execution (TX) and constrained-transactional-execution (CTX) facilities in some future Z system. During the development of the facility, it showed significant (incredible!) performance benefits in lock elision; it was also touted by the Java development team for its speculative-execution characteristics. Having been retired for over four years now, I cannot speak to the rationale (or irrationale) for planning on the facilities' removal. One might speculate that the minimal usage of the facilities did not justify the ongoing complexity of their implementation (TX is REALLY complex). As with any new architectural feature, it takes quite a while before many ISVs and customers exploit it. Having to dual-path one's code to account for the presence or absence of such a facility only prolongs the delay in exploitation. Consider how long it takes for an OS's level-set to catch up with the ever-evolving architecture. But if TX was such a hot feature, why wasn't its exploitation by IBM's own software sufficient to justify the obvious benefits that it provided? As the announcement letter said, "In some future IBM Z hardware system family, the transactional execution and constrained transactional execution facility will no longer be supported." Perhaps this ambiguity opens the possibility to a change of heart on IBM's part if enough customers and ISVs protest loudly enough ... but I doubt it. As to Mr. Shaw's comment about "feeling kinda 'had' now" ... yeah, that's a polite way to put it.
Re: Removal of transactional execution facility
On 4/14/2022 10:35 AM, David Cole wrote: Note, "dual path'ing" your code applies to TX, not to CTX. That's true if your minimum supported z/OS release is z/OS 2.4. Not even IBM is that aggressive! If your product still supports z/OS 2.3 or less, you must dual-path CTX as well. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Removal of transactional execution facility
Thanks for the correction, Ed. I didn't know that. -Dave At 4/14/2022 07:59 PM, Ed Jaffe wrote: On 4/14/2022 10:35 AM, David Cole wrote: Note, "dual path'ing" your code applies to TX, not to CTX. That's true if your minimum supported z/OS release is z/OS 2.4. Not even IBM is that aggressive! If your product still supports z/OS 2.3 or less, you must dual-path CTX as well. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Removal of transactional execution facility
On 4/15/2022 1:49 AM, David Cole wrote: Thanks for the correction, Ed. I didn't know that. -Dave "If your product still supports z/OS 2.3 or less, you must dual-path CTX as well." And this is precisely the reason CTX hasn't had the widespread adoption unrealistically expected by the hardware designers. z/OS 2.3 goes out of support in September of this year. The "avalanche" of CTX usage should begin after that -- although many ISV products are still supporting z/OS 2.2 (we do with some products) and some perhaps even z/OS 2.1. Using our (E)JES support roadmap as an example, we would not be able to take advantage of CTX without bifurcation until the release scheduled for GA in September 2024. JES3plus, which is on a more aggressive support schedule that exactly matches IBM, would not be able to use CTX without bifurcation until the September 2023 release. As I understand things, this roll-out delay is all because, even though z/OS 2.3 required z12 hardware, TX/CTX was not supported by z/VM until z/VM 6.4 and someone (I really do not know who ... but I can guess) decided z/OS 2.3 needed to support z/VM environments older than z/VM 6.4. Probably some *XTRA-LARG* customer had a conniption fit at the idea of upgrading their z/VMs to 6.4 or higher. Had that z/VM 6.4 ALS been allowed for z./OS 2.3, PSI would have put out a CTX-enabled JES3plus release *LAST* September and (E)JES would follow suit *THIS* September! I have no doubt we would have already by now seen numerous other CTX-enabled ISV and IBM products as well... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Removal of transactional execution facility
The "fit" part of "conniption fit" is actually redundant. The definition of 'conniption' reads: " a fit of rage or hysterics." Example sentence: "The casting choice gave the writers a conniption." (I did not know this either until I looked up the definition of "conniption".)
