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 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?
-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
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 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?
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 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?
-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?
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 -- 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?
-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?
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
