On a z13 we could access data in the PSA in the 2048 to 4095 range without
going into key 0. The specific field is PSASVT.
If you can prove that, then please report it immediately as a defect. But
I'd think you can't.
Is it possible that you used to access the SVT via CVTSVT?
Peter Relson
0 9:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Strange S0C4 on z15
Caution! This message was sent from outside your organization.
The first machine to implement ESA/370 was the 3090E. This was done via
microcode updates (since the 3090E hardware was designed prior to ESA). It was
not pos
TSERV.UA.EDU
> Date: 08/19/2020 09:07 PM
> Subject: Re: Strange S0C4 on z15
> Sent by: "IBM Mainframe Discussion List"
>
> Some months ago I asked a question regarding the relevance of the
> ORIGIN parm on a DSPSERV macro. During that time I came across older
> doc
@LISTSERV.UA.EDU
Subject: Re: Strange S0C4 on z15
Caution! This message was sent from outside your organization.
Fetch-protection-override (cr0.38) allowed the OS to put fetch protection on
page0 while allowing (legacy) access to 0-2047.
Don't know which hardware level allowed exploitation.
On Wed, 19 Aug
Seems like the real question is how does it work on a z13? 2048-4095
(x'800-FFF') are *supposed* to be key0 fetch-protected.
"Fetch Protection Override" (CR0:38) is to allow everyone to fetch from
0-2047 (x'0-7FF'), while leaving 2048-4095 fetch protection in effect. It
is not a new feature,
: Wednesday, August 19, 2020 4:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Strange S0C4 on z15
[ External - This message originated Externally. Use proper judgement and
caution with attachments, links, or responses. ]
So I had an S0C4 one time - turned out the vendor had used an instruction
Of
Christopher Y. Blaicher
Sent: Wednesday, August 19, 2020 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Strange S0C4 on z15
We have a program that ran fine on a z13 that now gets an S0C4 on a z15.
On a z13 we could access data in the PSA in the 2048 to 4095 range without
going into key 0. The specific
Fetch-protection-override (cr0.38) allowed the OS to put fetch protection on
page0 while allowing (legacy) access to 0-2047.
Don't know which hardware level allowed exploitation.
On Wed, 19 Aug 2020 19:11:33 + "Christopher Y. Blaicher"
wrote:
:>We have a program that ran fine on a z13
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Beaver
Sent: Wednesday, August 19, 2020 3:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Strange S0C4 on z15
[ External - This message originated Externally. Use proper judgement and
caution with attachments, links, or responses. ]
What
What was your zOS version and what is it now?
Sent from my iPhone
I promise you I can’t type or
Spell on any smartphone
> On Aug 19, 2020, at 14:21, Christopher Y. Blaicher
> wrote:
>
> We have a program that ran fine on a z13 that now gets an S0C4 on a z15.
> On a z13 we could access
We have a program that ran fine on a z13 that now gets an S0C4 on a z15.
On a z13 we could access data in the PSA in the 2048 to 4095 range without
going into key 0. The specific field is PSASVT.
To get to that data now, we have to do a MODESET to key zero.
Anyone else find this as a problem?
11 matches
Mail list logo
