Re: Can FRR prevent ESTAE from seeing registers?

[Craddock, Chris]

> I have an FRR that erases sensitive material from storage areas before
it
> percolates an ABEND. I also want to erase the registers so that any
ESTAE
> that may get subsequent control cannot see the error-time registers. I
> want the ESTAE to see zeroes in its SDWA.
> 
> The error-time registers may also have sensitive material that I don't
> want exposed to a user program that is using my service routine.
> 
> Is there a clean (IBM supported) way to achieve this?

AFAIK you can just scribble on the SDWA. What ever you leave there is
seen by subsequent error recovery exits of the same class. 

See
 

or  

I am not completely certain that also applies for FRR percolation back
to a non-FRR routine. But it -IS- documented that SDWACOMU is copied
from one SDWA to the next, so you can definitely use SDWACOMU to pass
footprint info from an FRR to a non-FRR environment. 

So if you always conspire so that the top of the non-FRR recovery chain
is one of your own recovery exits, you can have that exit notice your
private footprint information in SDWACOMU and do whatever you want with
the SDWA that gets passed along when you percolate. Kinda messy, but
effective.

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can FRR prevent ESTAE from seeing registers?

[Jeffrey D. Smith]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Craddock, Chris
> Sent: Thursday, May 10, 2007 11:11 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Can FRR prevent ESTAE from seeing registers?
> 
> > I have an FRR that erases sensitive material from storage areas before
> it
> > percolates an ABEND. I also want to erase the registers so that any
> ESTAE
> > that may get subsequent control cannot see the error-time registers. I
> > want the ESTAE to see zeroes in its SDWA.
> >
> > The error-time registers may also have sensitive material that I don't
> > want exposed to a user program that is using my service routine.
> >
> > Is there a clean (IBM supported) way to achieve this?
> 
> AFAIK you can just scribble on the SDWA. What ever you leave there is
> seen by subsequent error recovery exits of the same class.
> 
> See
> <http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A800/18.
> 2.2.2?DT=20010118152433#HDRSDWAUSE>
> 
> or <http://tinyurl.com/2rwe2f>
> 
> I am not completely certain that also applies for FRR percolation back
> to a non-FRR routine. But it -IS- documented that SDWACOMU is copied
> from one SDWA to the next, so you can definitely use SDWACOMU to pass
> footprint info from an FRR to a non-FRR environment.
> 
> So if you always conspire so that the top of the non-FRR recovery chain
> is one of your own recovery exits, you can have that exit notice your
> private footprint information in SDWACOMU and do whatever you want with
> the SDWA that gets passed along when you percolate. Kinda messy, but
> effective.
> 
> CC

Sigh... I am writing a service routine called by clients that must not
see the error-time registers. The SDWA is completely reallocated for
the transition between FRR and ESTAE processing, with only the SDWACOMU
copied to the new SDWA from the old SDWA. However, the client won't care
about that field. The client ESTAE routines are not mine.

My FRR is established under a stacking PC routine. I cannot use an ARR
to muck with the SDWA, because RTM will reallocate the SDWA upon
subsequent percolations due to storage key changes. My ARR will get a
key zero SDWA. Subsequent client ESTAE routines get a key 8 SDWA.

Sigh...again.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can FRR prevent ESTAE from seeing registers?

[Craddock, Chris]

> Sigh... I am writing a service routine called by clients that must not
> see the error-time registers. The SDWA is completely reallocated for
> the transition between FRR and ESTAE processing, with only the
SDWACOMU
> copied to the new SDWA from the old SDWA. However, the client won't
care
> about that field. The client ESTAE routines are not mine.
> 
> My FRR is established under a stacking PC routine. I cannot use an ARR
> to muck with the SDWA, because RTM will reallocate the SDWA upon
> subsequent percolations due to storage key changes. My ARR will get a
> key zero SDWA. Subsequent client ESTAE routines get a key 8 SDWA.

Peter or Jim or another IBM-er may correct me, but I think that any
changes you make in the (register) contents of the SDWA are passed along
on percolation, regardless of key transitions. The only place that
doesn't hold is for percolation from (RTM1) the oldest FRR to (RTM2) the
newest non-FRR. And in that case you can use SDWACOMU to set a
footprint. 

If your PC has an ARR, then by definition that's always the newest
non-FRR and it will be given control if your FRR elects to percolate. In
that case you could use SDWACOMU to tell yourself to rearrange the SDWA
appropriately so your caller's recovery does not see anything it
shouldn't. 

Here we're assuming you're going to percolate. I would suggest your
strategy should be to have your ARR clean up and retry directly to a PR
instruction. That PR would pop the PC entry and guarantee that your
caller always gets their key, state and registers put back together
correctly. At worst they would just get a nasty return code. 

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can FRR prevent ESTAE from seeing registers?

[Peter Relson]

Only by retrying.

If you cannot retry, it is your responsibility not to put things into
registers if they are sensitive in nature (not that that is necessarily
particularly feasible).

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can FRR prevent ESTAE from seeing registers?

[Jim Mulder]

IBM Mainframe Discussion List  wrote on 05/11/2007 
12:38:08 PM:

> When I have sensitive information in the general registers, I am not
> vulnerable to an access exception (all client data has already been
> copied to my protected storage areas).
> 
> When I am vulnerable to an access exception for client storage, I do
> not have sensitive information in the general registers.
> 
> Thus, the only situation that worries me is DETACH or CANCEL 
interrupting
> me when I have sensitive information in the general registers; I have an
> FRR defined at that time. Will the DETACH or CANCEL defer until I delete
> my FRR?

  Keep in mind that when your task gets interrupted by an I/O or
External interrupt, the GPRs are saved in the TCB/STCB (or IHSA if the 
local lock is held).  These areas are not fetch protected and are thus
visible to any program running in your address space.

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can FRR prevent ESTAE from seeing registers?

[Jeffrey D. Smith]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Peter Relson
> Sent: Friday, May 11, 2007 5:28 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Can FRR prevent ESTAE from seeing registers?
> 
> Only by retrying.
> 
> If you cannot retry, it is your responsibility not to put things into
> registers if they are sensitive in nature (not that that is necessarily
> particularly feasible).
> 
> Peter Relson

If I have a non-empty FRR stack, will DETACH or CANCEL processing defer
until the FRR stack is empty?

When I have sensitive information in the general registers, I am not
vulnerable to an access exception (all client data has already been
copied to my protected storage areas).

When I am vulnerable to an access exception for client storage, I do
not have sensitive information in the general registers.

Thus, the only situation that worries me is DETACH or CANCEL interrupting
me when I have sensitive information in the general registers; I have an
FRR defined at that time. Will the DETACH or CANCEL defer until I delete
my FRR?


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can FRR prevent ESTAE from seeing registers?

[Peter Relson]

Given everything that has been posted, the conclusion is that your best
chance for keeping things "not visible" is being disabled. You will then
not be interrupted and cannot be canceled. The local lock would prevent
cancels, but not the interrupt cases that Jim Mulder mentioned.

But even with that, there are conceivable non-retryable machine checks that
can occur.

Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can FRR prevent ESTAE from seeing registers?

[Jeffrey D. Smith]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Peter Relson
> Sent: Sunday, May 13, 2007 7:51 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Can FRR prevent ESTAE from seeing registers?
> 
> Given everything that has been posted, the conclusion is that your best
> chance for keeping things "not visible" is being disabled. You will then
> not be interrupted and cannot be canceled. The local lock would prevent
> cancels, but not the interrupt cases that Jim Mulder mentioned.
> 
> But even with that, there are conceivable non-retryable machine checks
> that
> can occur.
> 
> Peter Relson

Unfortunately, I must reference pageble storage. I am using EUT=YES frr.

The fact that MVS has several important storage areas that are
fetchable, like the TCB/STCB/IHSA and linkage stack, leaves several
"holes" that cannot be plugged.

It's not a huge concern for me, since my product now requires the
client program to be APF-authorized and therefore "trusted".

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html