Removal of transactional execution facility

[Ngan, Robert (DXC Luxoft)]

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

[Mike Shaw]

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.

[Ngan, Robert (DXC Luxoft)]

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 <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Mike Shaw
Sent: Wednesday, April 6, 2022 15:23
To: ASSEMBL...@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) < rober...@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

[Dan Greiner]

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.

[Ngan, Robert (DXC Luxoft)]

Hmmm, you mention "speculative execution". Maybe that make it vulnerable to meltdown/spectre type attacks.

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Dan Greiner
Sent: Wednesday, April 6, 2022 17:47
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Removal of transactional execution facility

[Gary Weinhold]

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: wein...@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.

[Tony Harminc]

On Wed, 6 Apr 2022 at 19:47, Ngan, Robert (DXC Luxoft)
<rober...@dxc.com> 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.

[Ed Jaffe]

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.

[Paul Gilmartin]

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

[Ed Jaffe]

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]

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.
>
>

[Paul Gilmartin]

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

[David Cole]

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)

[Ed Jaffe]

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.

[David Cole]

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

[Ed Jaffe]

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...

[paul schuster]

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".)