Discussion:
STORAGE KEY of loaded executable
(too old to reply)
Thomas David Rivers
2021-01-31 23:34:11 UTC
Permalink
I have a situation where I LOAD a program, with a PSW KEY of 8,
then branch to it.

The program switches to KEY 9, but wants to reference some
data in the loaded CSECT (say, for example, a =F constant in the
literal area.)

This blows up, I'm guessing because the key isn't the same as the
loaded module's memory (the address appears to be fine.)

This brings up a couple of questions:

When you LOAD a program, how do you control the KEY
for the memory the LOAD'd program occupies? Can you, or
does z/OS always LOAD (non-auth) programs in KEY=8?

When you switch KEYs, how do you retain access to the
program's memory for constants and things?

And - to get more complicated - when a blob of AUTHORIZED
code loads something, say, some system exit or something; what
is the STORAGE KEY of the memory that code is loaded in. That
program may get entered with a KEY=0, but will need access to
it's own CSECT.

And - It's not quite clear to me, but does the STORAGE KEY
get examined during the fetch-execute cycle of program
execution. If my module is in memory with KEY=8, and I change
the key with an SPKA instruction; can I actually retrieve the
next instruction to execute? Just where does the key-check occur?

- Dave R. -
--
***@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
Seymour J Metz
2021-02-01 00:30:19 UTC
Permalink
"In this case, the control program places the module in subpool 252. When choosing between subpools
244 and 251. the control program uses:
• Subpool 244 only when within a task that was created by ATTACHX with the KEY=NINE parameter
• Subpool 251in all other cases
Subpool 244 is not fetch protected and has a storage key equal to your PSW key. Subpool 251 is fetch
protected and has a storage key equal to your PSW key. Subpool 252 is not fetch protected and has
storage key 0."


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-***@LISTSERV.UA.EDU] on behalf of Thomas David Rivers [***@DIGNUS.COM]
Sent: Sunday, January 31, 2021 6:34 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: STORAGE KEY of loaded executable

I have a situation where I LOAD a program, with a PSW KEY of 8,
then branch to it.

The program switches to KEY 9, but wants to reference some
data in the loaded CSECT (say, for example, a =F constant in the
literal area.)

This blows up, I'm guessing because the key isn't the same as the
loaded module's memory (the address appears to be fine.)

This brings up a couple of questions:

When you LOAD a program, how do you control the KEY
for the memory the LOAD'd program occupies? Can you, or
does z/OS always LOAD (non-auth) programs in KEY=8?

When you switch KEYs, how do you retain access to the
program's memory for constants and things?

And - to get more complicated - when a blob of AUTHORIZED
code loads something, say, some system exit or something; what
is the STORAGE KEY of the memory that code is loaded in. That
program may get entered with a KEY=0, but will need access to
it's own CSECT.

And - It's not quite clear to me, but does the STORAGE KEY
get examined during the fetch-execute cycle of program
execution. If my module is in memory with KEY=8, and I change
the key with an SPKA instruction; can I actually retrieve the
next instruction to execute? Just where does the key-check occur?

- Dave R. -

--
***@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://secure-web.cisco.com/14WxsDY-ayEIw4Txd4CUMcWempgt1bm-X7QTZLrVnB1i6y_TA8841bEosQ2fvFaGtux7s2inbpaPacpuiMargzng8gwxFV5gOEoaTqqAVgLlVYVvpTX2b8HEPP7qMh32meHrzoDeYi2YlVQSamQ6-5nyyePmZACHdPPnhUvNFSMsPQLj-4l8ESe4ScBrJfxBMIHHKL2yQwzbh8HI3XoyU_GR8mttfo6SMzk6InfeXYnQxY4NusZuxHoEyR2dPPaP-Z-X9x6iVDSEyz0XmBMh2V9XS7D-WNOSRJI_UP0aL0jgj67GzxbodARuYB0l7Spm8fL2KJjam5mKuznS8nPE3NzMsL-xju1mRq3tY0IrtZmxs7JWt_YMmIWy1oG3T82MK-nf30qmZ5Ad5Hnoaw941mHq5tx8ddGWQ_fD4wybqxyPy0EysALY5YXjajS7ipLcO/http%3A%2F%2Fwww.dignus.com

----------------------------------------------------------------------
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
Binyamin Dissen
2021-02-01 11:06:59 UTC
Permalink
On Sun, 31 Jan 2021 18:34:11 -0500 Thomas David Rivers <***@DIGNUS.COM>
wrote:

:>I have a situation where I LOAD a program, with a PSW KEY of 8,
:>then branch to it.

:>The program switches to KEY 9, but wants to reference some
:>data in the loaded CSECT (say, for example, a =F constant in the
:>literal area.)

:>This blows up, I'm guessing because the key isn't the same as the
:>loaded module's memory (the address appears to be fine.)

:>This brings up a couple of questions:

:> When you LOAD a program, how do you control the KEY
:> for the memory the LOAD'd program occupies? Can you, or
:> does z/OS always LOAD (non-auth) programs in KEY=8?

If you mark the module refreshable it should nowadays be loaded into SP=252
which is not fetch protected.

:> When you switch KEYs, how do you retain access to the
:> program's memory for constants and things?

IF the program is in fetch protected storage, you do not (as you saw).

:> And - to get more complicated - when a blob of AUTHORIZED
:> code loads something, say, some system exit or something; what
:> is the STORAGE KEY of the memory that code is loaded in. That
:> program may get entered with a KEY=0, but will need access to
:> it's own CSECT.

Well, there MVS acts as a sort of nanny and if you ask for SP=0 when in key
zero it really gives you SP=252. You need to specify SP=250 if you want task
zero.

But the STORAGE macro certainly allows you to allocate storage that you do not
have current access to, such as a supervisor state program in key 1 can
allocate key 3 or key 8, and should it make an improper reference to the
storage it will PIC-4.

:> And - It's not quite clear to me, but does the STORAGE KEY
:> get examined during the fetch-execute cycle of program
:> execution. If my module is in memory with KEY=8, and I change
:> the key with an SPKA instruction; can I actually retrieve the
:> next instruction to execute? Just where does the key-check occur?

I notice that the POPs does not say that it causes a flush of the instruction
cache but it would have to do something similar for integrity. Changing the
PSW key to something that does not have the ability to fetch from the PSW
location should cause a PIC-4.

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Thomas David Rivers
2021-02-01 12:06:36 UTC
Permalink
Post by Binyamin Dissen
:> When you LOAD a program, how do you control the KEY
:> for the memory the LOAD'd program occupies? Can you, or
:> does z/OS always LOAD (non-auth) programs in KEY=8?
If you mark the module refreshable it should nowadays be loaded into SP=252
which is not fetch protected.
I have to admit to not looking for it yet - but do you have
a pointer to the doc for this? Schmuel described the various
Subpools and fetchability attributes which I was able to find
via a google text search. These seem to be described in the
ATTACHX documentation... but that must also apply to LOAD
(I suppose???)

Thanks for the pointer about REFRESH (REFR option on binder),
I'll look for more info.

The downside of REFR is it defeats the use of debuggers which
modify the code-stream to insert break-points... but, it is what it is...

- Thanks -
- Dave R. -
--
***@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
Seymour J Metz
2021-02-01 13:35:39 UTC
Permalink
Using the REFRPROT statement
Use the REFRPROT statement type to specify that REFR programs are
protected from modification by placing them in key 0, non-fetch protected storage,
and page protecting the full pages.
Therefore, any parts of the program that are on partial pages are not page-protected.
For more information on protectionof REFR programs, see
z/OS MVS Program Management: User's Guide and Reference

That's Shmuel



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-***@LISTSERV.UA.EDU] on behalf of Thomas David Rivers [***@DIGNUS.COM]
Sent: Monday, February 1, 2021 7:06 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: STORAGE KEY of loaded executable
Post by Binyamin Dissen
:> When you LOAD a program, how do you control the KEY
:> for the memory the LOAD'd program occupies? Can you, or
:> does z/OS always LOAD (non-auth) programs in KEY=8?
If you mark the module refreshable it should nowadays be loaded into SP=252
which is not fetch protected.
I have to admit to not looking for it yet - but do you have
a pointer to the doc for this? Schmuel described the various
Subpools and fetchability attributes which I was able to find
via a google text search. These seem to be described in the
ATTACHX documentation... but that must also apply to LOAD
(I suppose???)

Thanks for the pointer about REFRESH (REFR option on binder),
I'll look for more info.

The downside of REFR is it defeats the use of debuggers which
modify the code-stream to insert break-points... but, it is what it is...

- Thanks -
- Dave R. -

--
***@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://secure-web.cisco.com/1Fca2f4IZyQDVYdr-tstJBM0QiKvOzgzg94WT2h048B5kcwGwpOyiewu9F8yc-DmUE5IxyEX1shdLcwKPemLt6F9sCyPfueLpjDx_8DxXMbGz9S-e_C70qlP4OQjP3eYcoaQoC_iERsWYwJDrhfxOUh1J8gFjYF9kMnNKgf8Nrj8yK4Xb4Ge0Reg3P-yKKCVRlaQztNOgDRtszxarzAZobwBPk07aruzQDx89h57i2M96Hbq9jVg_wS7-tHzzf9H5dtt5uvH51UVkSr6kOGU0WalGJCuZYzWtJ7t2-Sb1QarOI8Mlzh40ZvO2iGhVnKMwICQMQ_BqdW2QV9I8IamrAtmJuB_-kGFQeGa-nCbuqB5vlLyh5T_sR5IZbV4twskfvJf-TmGDMkKun49waLNkEgbHfD3iep5-o0pMk0wwfoP_1ZZ4Rd5AJXk4o8wjmpoo/http%3A%2F%2Fwww.dignus.com

----------------------------------------------------------------------
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
Seymour J Metz
2021-02-01 13:45:53 UTC
Permalink
The behavior for REFR is subject to operator and parmlib control. RENT goes into key 0 if the library concatenation is APF.

There's no reason to flush the cache, and doing so would be a major performance hit. With luck there an IBM Systems Journal article or redbook on the I-unit of current processors; if not, there should be.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-***@LISTSERV.UA.EDU] on behalf of Binyamin Dissen [***@DISSENSOFTWARE.COM]
Sent: Monday, February 1, 2021 6:05 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: STORAGE KEY of loaded executable

On Sun, 31 Jan 2021 18:34:11 -0500 Thomas David Rivers <***@DIGNUS.COM>
wrote:

:>I have a situation where I LOAD a program, with a PSW KEY of 8,
:>then branch to it.

:>The program switches to KEY 9, but wants to reference some
:>data in the loaded CSECT (say, for example, a =F constant in the
:>literal area.)

:>This blows up, I'm guessing because the key isn't the same as the
:>loaded module's memory (the address appears to be fine.)

:>This brings up a couple of questions:

:> When you LOAD a program, how do you control the KEY
:> for the memory the LOAD'd program occupies? Can you, or
:> does z/OS always LOAD (non-auth) programs in KEY=8?

If you mark the module refreshable it should nowadays be loaded into SP=252
which is not fetch protected.

:> When you switch KEYs, how do you retain access to the
:> program's memory for constants and things?

IF the program is in fetch protected storage, you do not (as you saw).

:> And - to get more complicated - when a blob of AUTHORIZED
:> code loads something, say, some system exit or something; what
:> is the STORAGE KEY of the memory that code is loaded in. That
:> program may get entered with a KEY=0, but will need access to
:> it's own CSECT.

Well, there MVS acts as a sort of nanny and if you ask for SP=0 when in key
zero it really gives you SP=252. You need to specify SP=250 if you want task
zero.

But the STORAGE macro certainly allows you to allocate storage that you do not
have current access to, such as a supervisor state program in key 1 can
allocate key 3 or key 8, and should it make an improper reference to the
storage it will PIC-4.

:> And - It's not quite clear to me, but does the STORAGE KEY
:> get examined during the fetch-execute cycle of program
:> execution. If my module is in memory with KEY=8, and I change
:> the key with an SPKA instruction; can I actually retrieve the
:> next instruction to execute? Just where does the key-check occur?

I notice that the POPs does not say that it causes a flush of the instruction
cache but it would have to do something similar for integrity. Changing the
PSW key to something that does not have the ability to fetch from the PSW
location should cause a PIC-4.

--
Binyamin Dissen <***@dissensoftware.com>
http://secure-web.cisco.com/1rk1kzDQ1dsQLEjbFIOdTLgfWKkMk_vMLQiQ6XbnsMve7RFps3Az-Pvi4Ha4_hhLa58Bzcqo3XlG-W4hVLLUB3ZQa1if0tXXo1yla2P3yhSSIYHKPbxfM4X4GeupcpCBAHhazrlRh9D_qk0pV21XDo9ZZypKN_56nB7leTnW_YhTD1ZSoHHcAsN2SX4U4ppIoQtsvEfQgYUs7sqaQXlLrFSwLvpG-a0Y6j_Ki2pog7LntjtEqUi_Hz0-ry0_Xu_zBCRC7mcBJLBp-7k4wBcuax_tDlfokH9M4LwOmIanp541XIxipkGLJEhyC3mY_Xo8aX3T4JKW88vZ_cb6NHHLV4d70zPgf9t0zFFv87-RLIU6-DBAF2XuDLlLdH1t4HKttl5ebSFWJVNifKH-KB65KoACP6YVEDl-DuOsK0-BIFPcysrLi3oRlSOUvXrzhMOJg/http%3A%2F%2Fwww.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
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
Binyamin Dissen
2021-02-02 12:21:30 UTC
Permalink
On Mon, 1 Feb 2021 13:45:45 +0000 Seymour J Metz <***@GMU.EDU> wrote:

:>There's no reason to flush the cache, and doing so would be a major performance hit. With luck there an IBM Systems Journal article or redbook on the I-unit of current processors; if not, there should be.

How does the cache work?

Does MVS preserve the I-cache if a different thread is executing the same
address (or share the I-cache between different CPUs)?

Does it validate that the source of the cache is accessible whenever the SPKA
is issued, i.e., does the cache have key and fetch protect bits?

Any pre-executed instructions will have to be rolled back, correct?

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2021-02-02 13:39:44 UTC
Permalink
Post by Binyamin Dissen
:>There's no reason to flush the cache, and doing so would be a major performance hit. With luck there an IBM Systems Journal article or redbook on the I-unit of current processors; if not, there should be.
How does the cache work?
Does MVS preserve the I-cache if a different thread is executing the same
address (or share the I-cache between different CPUs)?
Just to be clear, what he's talking about has nothing whatever to do wit
MVS or any other operating system. It's the IBM Z processor hardware
doing this...
Post by Binyamin Dissen
Does it validate that the source of the cache is accessible whenever the SPKA
is issued, i.e., does the cache have key and fetch protect bits?
Any pre-executed instructions will have to be rolled back, correct?
Results of instruction fetch, instruction decode, address generation,
operand fetch, etc. down the "wrong" path are discarded.
--
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.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2021-02-02 14:37:38 UTC
Permalink
Implementation is model dependent. The hardware has to preserve enough information to comply with the architecture. I know of no reason for MVS to purge the i-cache under normal circumstances.

If the I-cache includes key and STO then I know of no reason not to share it.

There is no need to validate the key in the cache after SPKA; what is necessary is to vallidate if prior to final execution. Consider code that sets the key to 8, does something, then sets the key to 9. Do you really want to invalidate and refetch the second block of code after the first SPKA. Now, the designers have to make tradeoffs between circuit complexity and performance, so there might be purges that are not logically necessary. But, again, such matters are model dependent.

If there is speculative execution and an instruction is not in the right key, then it has to be rolled back. But it's only the last key change before the instruction that matters.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-***@LISTSERV.UA.EDU] on behalf of Binyamin Dissen [***@DISSENSOFTWARE.COM]
Sent: Tuesday, February 2, 2021 7:21 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: STORAGE KEY of loaded executable

On Mon, 1 Feb 2021 13:45:45 +0000 Seymour J Metz <***@GMU.EDU> wrote:

:>There's no reason to flush the cache, and doing so would be a major performance hit. With luck there an IBM Systems Journal article or redbook on the I-unit of current processors; if not, there should be.

How does the cache work?

Does MVS preserve the I-cache if a different thread is executing the same
address (or share the I-cache between different CPUs)?

Does it validate that the source of the cache is accessible whenever the SPKA
is issued, i.e., does the cache have key and fetch protect bits?

Any pre-executed instructions will have to be rolled back, correct?

--
Binyamin Dissen <***@dissensoftware.com>
http://secure-web.cisco.com/1g-7fia0NcdlvAUroS_CZ7R2AV8DyMZE3b1LPPPJTzH79cOlOAeTaBWLpdK2p0t96V4ZtMYCXOScGlyngDF2ZCOcp37oXfcQ0DvM7CZE2DFnVQVu8OpKrEDMF_0adlAYM4D1vkL4UDIECC4TVpSFHAtakw5toKlh_6kp0QNMiP98Vzt-5RUhWDlhSGp2PhvtrpMXZKOGvIp_v5GYPGcUoZOMgFCb2tSNheQPRnw4--qvNLzW3owJLyusoxUr12y3ShiwjXHPKX93BdEvFHgG2jn7H-HOPaqTZSHGPJ9it92SaHFGlfQoavXI5kbLm3XYX7hpsvr7aIVeroAui8xPzsnHh0ZYB7LksDt0p5E4kJQ8E6gAukjDTWMCYbVOwv-G3Ltle8YBZjLt-NqDaENkcTAwg0Xuv9-utb8O_dL8o-pkecpsQhf2YV-MRZGOX3LoT/http%3A%2F%2Fwww.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
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
Peter Relson
2021-02-01 13:49:37 UTC
Permalink
Shmuel posted the relevant section.

The really relevant point is that subpool 251 is fetch-protected (and
subpool 252 is not)
If you switch out of the subpool 251 key (and the module is in subpool 251
storage, not subpool 252), then you have no access to the storage of your
program and thus, yes, you will program check attempting to fetch the
instruction.

If your program is loaded into subpool 252 (key 0, not fetch protected)
any key can read it.

<snip>
when a blob of AUTHORIZED code loads something, say, some system exit or
something; what
is the STORAGE KEY of the memory that code is loaded in. That
program may get entered with a KEY=0, but will need access to its own
CSECT.
</snip>
The same rules apply.


May I ask why you need to switch to key 9? That is very atypical. I
believe that the Storage Protect Override facility, as implemented in z/OS
with Key 9, was created so that CICS transactions could avoid accidental
overlays of CICS key 8 storage. So unless you're trying super-hard to
prevent yourself from overlaying your own key 8 storage, you would not
typically get into key 9.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Thomas David Rivers
2021-02-01 22:02:48 UTC
Permalink
Post by Peter Relson
.
May I ask why you need to switch to key 9? That is very atypical. I
believe that the Storage Protect Override facility, as implemented in z/OS
with Key 9, was created so that CICS transactions could avoid accidental
overlays of CICS key 8 storage. So unless you're trying super-hard to
prevent yourself from overlaying your own key 8 storage, you would not
typically get into key 9.
Peter Relson
z/OS Core Technology Design
Hi Peter!

I'm playing around with some tests and was switching keys,
and didn't want to mess with authorized code. So I just picked
the next one up to 8. There was nothing "special" in my choice
of 9.

Same kind of idea - trying to just switch to key 9 and make sure
things don't blow up, or accidently reference the previously allocated
key 8 memory.

But I bumped into some references to the previous memory that
are intentional/needed... so it's a bit of a squirrely mess at this point.

- Dave R. -
--
***@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
Dave Barry
2021-02-04 17:28:36 UTC
Permalink
I dimly recall from decades ago a recommendation to run CICS in key 7. IIRC, it had something to do with aligning a buffer on a page boundary. Long obsolete advice, I'm sure.

======================================================================
Post by Peter Relson
.
May I ask why you need to switch to key 9? That is very atypical. I
believe that the Storage Protect Override facility, as implemented in
z/OS with Key 9, was created so that CICS transactions could avoid
accidental overlays of CICS key 8 storage. So unless you're trying
super-hard to prevent yourself from overlaying your own key 8 storage,
you would not typically get into key 9.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2021-02-02 14:05:07 UTC
Permalink
Post by Ed Jaffe
...
Post by Binyamin Dissen
Does it validate that the source of the cache is accessible whenever the SPKA
is issued, i.e., does the cache have key and fetch protect bits?
Any pre-executed instructions will have to be rolled back, correct?
Results of instruction fetch, instruction decode, address generation,
operand fetch, etc. down the "wrong" path are discarded.
Does this neutralize even the Spectre exploit?
https://xkcd.com/1938/

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2021-02-02 14:06:14 UTC
Permalink
<snip>
I'm playing around with some tests and was switching keys,
and didn't want to mess with authorized code. So I just picked
the next one up to 8. There was nothing "special" in my choice
of 9.
</snip>

Then you were playing with fire (well, program checks) and were kind of
lucky.
The only key that a non-APF-authorized key 8 program can switch to is key
9.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2021-02-03 13:10:19 UTC
Permalink
It's not so much the instruction cache but rather the instruction pipeline
that might need to be flushed.
As Ed Jaffe pointed out, anything done speculatively needs to be, and is,
re-evaluated (in general, thrown away and re-done).

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2021-02-04 19:43:27 UTC
Permalink
Flushing the pipeline is a trade-off between complexity and performance. It's certainly possible to design a pipeline that can handle key changes without flushing; whether it's worth the real estate is something that your engineers have to decides.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-***@LISTSERV.UA.EDU] on behalf of Peter Relson [***@US.IBM.COM]
Sent: Wednesday, February 3, 2021 8:09 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: STORAGE KEY of loaded executable

It's not so much the instruction cache but rather the instruction pipeline
that might need to be flushed.
As Ed Jaffe pointed out, anything done speculatively needs to be, and is,
re-evaluated (in general, thrown away and re-done).

Peter Relson
z/OS Core Technology Design


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