Re: Testing address validity
On Sat, 5 Mar 2022 at 19:48, Charles Mills wrote: > > I guess I am unclear on the sequence of events involved. Serious question, > not an argument: > > I have an ordinary problem state program that attempts to access storage > that it does not have access to. Obviously a S0C4 is the result. Let's say > the address is a valid virtual address (but the storage key is wrong) and > the page representing that virtual address is paged out. What is the > sequence of events that leads to the S0C4? Does the OS have to page in the > page so the hardware can generate a S0C4? That seems inefficient. [My interpretation of the PofO; yours may be different and/or just as good:] Keep in mind that pages (of virtual storage) don't have things like a storage key and change and reference bits. Only page frames (blocks of real storage) have that stuff. (Yes, there is the IVSK instruction, but that still ultimately deals with real storage, and will itself get a page fault if there is no valid translation to the real address of the page. I believe it exists to avoid the risk of an interrupt between LRA and ISK[E] that could otherwise arise.) So if the address is in a page that's paged out, the page table entry will be marked as invalid. This leads to a program interrupt 11 (page fault). If the virtual storage for that page is not allocated, then the program interrupt 11 will be converted into a S0C4 abend. If the page exists in a slot in a page dataset, z/OS will page it in and retry the failing instruction. If there is a key mismatch at that point it gets a program interrupt 4 (protection exception), and this is also turned into a S0C4 abend. So by this description, yes, the OS has to page in the page to discover the protection exception. But... If the Invalid bit is on in the page table entry, the other 63 bits are available for software use, and I imagine that z/OS keeps information there about the key and the status of the page in auxiliary storage, and so should be able to issue the S0C4 without having to do the page-in. But that's z/OS, not the architecture, and I don't know what it really does under those OCO covers. > And in any event, whatever the mechanism, why could not that mechanism > generate a condition code for this hypothetical new instruction rather than > a program interrupt? It could if the architecture defined a place to keep the key for the page. But as far as I know it doesn't. Tony H.
Re: Testing address validity
There really isone. If you're authorized, TPROT will help, but there are three problems: 1. It requires Supervisor mode. 2. I requires that you be in the correct addressing environment. 3. It gives a condition code three with no useful information if the data are paged out. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of João Reginato [jb.regin...@gmail.com] Sent: Saturday, March 5, 2022 7:44 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Testing address validity Hi Which is the best instruction to test if a virtual address is still valid to avoid an unexpected S0C4? TIA João
Re: Testing address validity
How would you handle CC 3 from TPROT? Does z/VSE have a facility to request a page-in without treating an invalid virtual address as an error? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Saturday, March 5, 2022 7:39 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity z/VSE and running on the callers TCB (for several z/VSE related reasons). Tony Thigpen Seymour J Metz wrote on 3/5/22 19:35: > As a subsystem, you should have your own recovery environment, so what you do > won't interfere with the caller's error recovery. Using a recovery routine, > whether to handle a program check or to handle the ABEND from an unhandled > program check, has two advantages: > > 1. It works when the data were paged out > > 2. It solves the time-of-check to time-of-use problem. > > > -- > Shmuel (Seymour J.) Metz > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=04%7C01%7Csmetz3%40gmu.edu%7C5eb4f155d5e348a4f78008d9ff09d6ef%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637821240001763574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Q3IlautNVBoE6qUYgjR%2FwOqI3QhfFhBJU6761VPOuSs%3D&reserved=0 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Tony Thigpen [t...@vse2pdf.com] > Sent: Saturday, March 5, 2022 5:11 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Testing address validity > > My thoughts. > > Since I support software that is called by any number of users, I would > like to validate that they provided valid parms. As a called subsystem, > I can't be messing with the callers error handling routines that may > already be handling SOC4s. I don't want to know if it's 'in storage', > just that it is accessible even if a page-fault is needed. > > I wish there was a simple: > TEST MEMORY AND BRANCH INVALID > operands R1 is a register pair with R1=address and R1+1=length to > validate. (Like an MVCL.) > > Instead of a SOC4, just branch to the address provided as the second > operand where I have placed an error handler. > > > > Tony Thigpen > > Paul Gilmartin wrote on 3/5/22 16:48: >> On Mar 5, 2022, at 05:44:41, João Reginato wrote: >>> >>> Which is the best instruction to test if a virtual address is still valid to >>> avoid an unexpected S0C4? >>> >> How is that information useful? >> >> Is its usefulness diminished by "an unexpected S0C4"? >> >> -- >> gil
Re: Testing address validity
Yes, and they will report it if TPROT gives cc=3. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jeremy Schwartz [115e2ee20c83-dmarc-requ...@listserv.uga.edu] Sent: Saturday, March 5, 2022 3:13 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity Just curious would the following macros work better as a replacement for TPROT in the requested case? IARBRVER, IARBRVEA, and IARBRVKA Regards, Jeremy Schwartz From: IBM Mainframe Assembler List on behalf of Philippe Leite Sent: Saturday, March 5, 2022 9:28 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity CAUTION: This message was sent from outside the company. Do not click links or open attachments unless you recognize the sender and know the content is safe. You can use TPROT for this purpose but it's a privileged instruction. Regards, Philippe Leite LAB Services - IBM Em sáb., 5 de mar. de 2022 09:45, João Reginato escreveu: > Hi > > Which is the best instruction to test if a virtual address is still valid > to > avoid an unexpected S0C4? > > > > TIA > > João > > > --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email.
Re: Testing address validity
It is not obvious that there will be an S0C4. ESPIE can intercept codes related to various types of protection. The general sequence of events is 1. You get a program check. The Supervisor determines that it needs to page something in. 2. Upon redispatch, you attempt to use the data 3. You get a program check. The Supervisor determines that it does not need to page anything in. 4. The Supervisor determines whether there is an active SPIE or ESPIE for the interrupt code. 5. If the interrupt is not handled, the Supervisor calls RTM for an S0C4. That's z/OS, not the hardware. 6. The Supervisor calls any recovery routines. In the case of paged out data with the wrong key, the interrupt code for steps 3-4 will be 04. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Saturday, March 5, 2022 7:48 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity I guess I am unclear on the sequence of events involved. Serious question, not an argument: I have an ordinary problem state program that attempts to access storage that it does not have access to. Obviously a S0C4 is the result. Let's say the address is a valid virtual address (but the storage key is wrong) and the page representing that virtual address is paged out. What is the sequence of events that leads to the S0C4? Does the OS have to page in the page so the hardware can generate a S0C4? That seems inefficient. And in any event, whatever the mechanism, why could not that mechanism generate a condition code for this hypothetical new instruction rather than a program interrupt? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Saturday, March 5, 2022 4:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity > How does the hardware not know the answer to that question? Because the hardware only knows about pages assigned to pages; it knows nothing about what has been paged out, as was previously noted. -- Shmuel (Seymour J.) Metz https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=04%7C01%7Csmetz3%40gmu.edu%7C1b7a1ea780c64d684a4408d9ff0b16a9%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637821245409672791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1ovNT%2FKa3OZ%2BcIzXUaJtHjw4t2lHbKxuAk6YUUekvAY%3D&reserved=0 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Saturday, March 5, 2022 6:17 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity > only the OS knows the answer to this question Am I suffering from some mental block? How does the hardware not know the answer to that question? If an instruction can cause a S0C4, why could an instruction not answer this question? The hardware "knows" about virtual addresses.
Re: Testing address validity
I guess I am unclear on the sequence of events involved. Serious question, not an argument: I have an ordinary problem state program that attempts to access storage that it does not have access to. Obviously a S0C4 is the result. Let's say the address is a valid virtual address (but the storage key is wrong) and the page representing that virtual address is paged out. What is the sequence of events that leads to the S0C4? Does the OS have to page in the page so the hardware can generate a S0C4? That seems inefficient. And in any event, whatever the mechanism, why could not that mechanism generate a condition code for this hypothetical new instruction rather than a program interrupt? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Saturday, March 5, 2022 4:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity > How does the hardware not know the answer to that question? Because the hardware only knows about pages assigned to pages; it knows nothing about what has been paged out, as was previously noted. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Saturday, March 5, 2022 6:17 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity > only the OS knows the answer to this question Am I suffering from some mental block? How does the hardware not know the answer to that question? If an instruction can cause a S0C4, why could an instruction not answer this question? The hardware "knows" about virtual addresses.
Re: Testing address validity
z/VSE and running on the callers TCB (for several z/VSE related reasons). Tony Thigpen Seymour J Metz wrote on 3/5/22 19:35: As a subsystem, you should have your own recovery environment, so what you do won't interfere with the caller's error recovery. Using a recovery routine, whether to handle a program check or to handle the ABEND from an unhandled program check, has two advantages: 1. It works when the data were paged out 2. It solves the time-of-check to time-of-use problem. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Saturday, March 5, 2022 5:11 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity My thoughts. Since I support software that is called by any number of users, I would like to validate that they provided valid parms. As a called subsystem, I can't be messing with the callers error handling routines that may already be handling SOC4s. I don't want to know if it's 'in storage', just that it is accessible even if a page-fault is needed. I wish there was a simple: TEST MEMORY AND BRANCH INVALID operands R1 is a register pair with R1=address and R1+1=length to validate. (Like an MVCL.) Instead of a SOC4, just branch to the address provided as the second operand where I have placed an error handler. Tony Thigpen Paul Gilmartin wrote on 3/5/22 16:48: On Mar 5, 2022, at 05:44:41, João Reginato wrote: Which is the best instruction to test if a virtual address is still valid to avoid an unexpected S0C4? How is that information useful? Is its usefulness diminished by "an unexpected S0C4"? -- gil
Re: Testing address validity
As a subsystem, you should have your own recovery environment, so what you do won't interfere with the caller's error recovery. Using a recovery routine, whether to handle a program check or to handle the ABEND from an unhandled program check, has two advantages: 1. It works when the data were paged out 2. It solves the time-of-check to time-of-use problem. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Saturday, March 5, 2022 5:11 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity My thoughts. Since I support software that is called by any number of users, I would like to validate that they provided valid parms. As a called subsystem, I can't be messing with the callers error handling routines that may already be handling SOC4s. I don't want to know if it's 'in storage', just that it is accessible even if a page-fault is needed. I wish there was a simple: TEST MEMORY AND BRANCH INVALID operands R1 is a register pair with R1=address and R1+1=length to validate. (Like an MVCL.) Instead of a SOC4, just branch to the address provided as the second operand where I have placed an error handler. Tony Thigpen Paul Gilmartin wrote on 3/5/22 16:48: > On Mar 5, 2022, at 05:44:41, João Reginato wrote: >> >> Which is the best instruction to test if a virtual address is still valid to >> avoid an unexpected S0C4? >> > How is that information useful? > > Is its usefulness diminished by "an unexpected S0C4"? > > -- > gil
Re: Testing address validity
Using an ESPIE will avoid an ABEND, as will the appropriate use of move with key. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Keven Hall [k...@k3n.us] Sent: Saturday, March 5, 2022 6:00 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity There’s no way to avoid an ABEND unless you use FRR, ARR,ESTAE etc. or unless your thread of execution has some explicit or implicit lock on the virtual storage. There’s no “safe “ instruction that serves you purpose. The archives are replete with discussions on this topic IIRC Regards, Keven > On Mar 5, 2022, at 16:11, Tony Thigpen wrote: > > My thoughts. > > Since I support software that is called by any number of users, I would like > to validate that they provided valid parms. As a called subsystem, I can't be > messing with the callers error handling routines that may already be handling > SOC4s. I don't want to know if it's 'in storage', just that it is accessible > even if a page-fault is needed. > > I wish there was a simple: > TEST MEMORY AND BRANCH INVALID > operands R1 is a register pair with R1=address and R1+1=length to validate. > (Like an MVCL.) > > Instead of a SOC4, just branch to the address provided as the second operand > where I have placed an error handler. > > > > Tony Thigpen > > Paul Gilmartin wrote on 3/5/22 16:48: >>> On Mar 5, 2022, at 05:44:41, João Reginato wrote: >>> >>> Which is the best instruction to test if a virtual address is still valid to >>> avoid an unexpected S0C4? >>> >> How is that information useful? >> Is its usefulness diminished by "an unexpected S0C4"? >> -- >> gil
Re: Testing address validity
> How does the hardware not know the answer to that question? Because the hardware only knows about pages assigned to pages; it knows nothing about what has been paged out, as was previously noted. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Saturday, March 5, 2022 6:17 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity > only the OS knows the answer to this question Am I suffering from some mental block? How does the hardware not know the answer to that question? If an instruction can cause a S0C4, why could an instruction not answer this question? The hardware "knows" about virtual addresses. Also FWIW, I would vote for @Tony's variant, where you could ask not only about a single byte, but about a block of some specified length. Programming note 2 would have to say "the results are only valid at the instant of execution." Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dan Greiner Sent: Saturday, March 5, 2022 11:09 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity Several years ago at SHARE, I did a presentation on various requests for new architecture. Such an instruction to determine accessibility was at the top of the list. So, I dragged out an architecture instruction template and designed one on the spot: Given a base register, index register, and long displacement using a standard RXY instruction format, set a condition code to indicate whether the access caused an exception. Oh, plus programming note 1: This instruction is absolutely useless! Upon reflection, my proposed PN#1 was not totally accurate. If you happened to be running in a non-virtual environment such as OS/MFT, things would work just swell. But for any OS that uses paging to present a virtual address space to the user, only the OS knows the answer to this question. So, you need to use an OS service to make the determination. As an alternative to setting up an ESPIE environment, you might want to consider transactional execution (TX, available on the z12 and up). In addition to its multiprocessing lock elision features, TX also provides an easy means for an application to do speculative execution by evading certain program-interruption conditions. For example: TBEGIN TDB,2 JNZ ABORTED ... speculatively access data. TEND If the code branches to the ABORTED label, a transaction diagnostic block is stored (except for CC1), and the program can determine what exception condition caused the abort and whether recovery is likely without OS intervention. See the TX section of Chapter 5 for more details.
Re: Testing address validity
> only the OS knows the answer to this question Am I suffering from some mental block? How does the hardware not know the answer to that question? If an instruction can cause a S0C4, why could an instruction not answer this question? The hardware "knows" about virtual addresses. Also FWIW, I would vote for @Tony's variant, where you could ask not only about a single byte, but about a block of some specified length. Programming note 2 would have to say "the results are only valid at the instant of execution." Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dan Greiner Sent: Saturday, March 5, 2022 11:09 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity Several years ago at SHARE, I did a presentation on various requests for new architecture. Such an instruction to determine accessibility was at the top of the list. So, I dragged out an architecture instruction template and designed one on the spot: Given a base register, index register, and long displacement using a standard RXY instruction format, set a condition code to indicate whether the access caused an exception. Oh, plus programming note 1: This instruction is absolutely useless! Upon reflection, my proposed PN#1 was not totally accurate. If you happened to be running in a non-virtual environment such as OS/MFT, things would work just swell. But for any OS that uses paging to present a virtual address space to the user, only the OS knows the answer to this question. So, you need to use an OS service to make the determination. As an alternative to setting up an ESPIE environment, you might want to consider transactional execution (TX, available on the z12 and up). In addition to its multiprocessing lock elision features, TX also provides an easy means for an application to do speculative execution by evading certain program-interruption conditions. For example: TBEGIN TDB,2 JNZ ABORTED ... speculatively access data. TEND If the code branches to the ABORTED label, a transaction diagnostic block is stored (except for CC1), and the program can determine what exception condition caused the abort and whether recovery is likely without OS intervention. See the TX section of Chapter 5 for more details.
Re: Testing address validity
> Store with Caller's PSW Key There are the various "move with specified key" instructions. Best practice for writing a PC routine requires that you make use of those or equivalent services. > But would such a facility be useful to an intruder I don't think it would provide any information that would not be provided by ordinary access with an ESPIE routine. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, March 5, 2022 2:52 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity On Mar 5, 2022, at 15:11:41, Tony Thigpen wrote: > > Since I support software that is called by any number of users, I would like to validate that they provided valid parms. As a called subsystem, I can't be messing with the callers error handling routines that may already be handling SOC4s. I don't want to know if it's 'in storage', just that it is accessible even if a page-fault is needed. > Interesting problem. How do Supervisor services, which might operate in a privileged state deal with wild reply buffer addresses? Might that provide a model? I could wish for a "Store with Caller's PSW Key" instruction. (Does cross-memory services provide something similar?) Let the callers handle the damage; it's their fault. But how to provide meaningful diagnostics? > I wish there was a simple: > TEST MEMORY AND BRANCH INVALID > operands R1 is a register pair with R1=address and R1+1=length to validate. (Like an MVCL.) > > Instead of a SOC4, just branch to the address provided as the second operand where I have placed an error handler. > But would such a facility be useful to an intruder probing for a weakness to exploit?
Re: Testing address validity
There’s no way to avoid an ABEND unless you use FRR, ARR,ESTAE etc. or unless your thread of execution has some explicit or implicit lock on the virtual storage. There’s no “safe “ instruction that serves you purpose. The archives are replete with discussions on this topic IIRC Regards, Keven > On Mar 5, 2022, at 16:11, Tony Thigpen wrote: > > My thoughts. > > Since I support software that is called by any number of users, I would like > to validate that they provided valid parms. As a called subsystem, I can't be > messing with the callers error handling routines that may already be handling > SOC4s. I don't want to know if it's 'in storage', just that it is accessible > even if a page-fault is needed. > > I wish there was a simple: > TEST MEMORY AND BRANCH INVALID > operands R1 is a register pair with R1=address and R1+1=length to validate. > (Like an MVCL.) > > Instead of a SOC4, just branch to the address provided as the second operand > where I have placed an error handler. > > > > Tony Thigpen > > Paul Gilmartin wrote on 3/5/22 16:48: >>> On Mar 5, 2022, at 05:44:41, João Reginato wrote: >>> >>> Which is the best instruction to test if a virtual address is still valid to >>> avoid an unexpected S0C4? >>> >> How is that information useful? >> Is its usefulness diminished by "an unexpected S0C4"? >> -- >> gil
Re: Testing address validity
On Mar 5, 2022, at 15:11:41, Tony Thigpen wrote: > > Since I support software that is called by any number of users, I would like > to validate that they provided valid parms. As a called subsystem, I can't be > messing with the callers error handling routines that may already be handling > SOC4s. I don't want to know if it's 'in storage', just that it is accessible > even if a page-fault is needed. > Interesting problem. How do Supervisor services, which might operate in a privileged state deal with wild reply buffer addresses? Might that provide a model? I could wish for a "Store with Caller's PSW Key" instruction. (Does cross-memory services provide something similar?) Let the callers handle the damage; it's their fault. But how to provide meaningful diagnostics? > I wish there was a simple: > TEST MEMORY AND BRANCH INVALID > operands R1 is a register pair with R1=address and R1+1=length to validate. > (Like an MVCL.) > > Instead of a SOC4, just branch to the address provided as the second operand > where I have placed an error handler. > But would such a facility be useful to an intruder probing for a weakness to exploit? -- gil
Re: Testing address validity
My thoughts. Since I support software that is called by any number of users, I would like to validate that they provided valid parms. As a called subsystem, I can't be messing with the callers error handling routines that may already be handling SOC4s. I don't want to know if it's 'in storage', just that it is accessible even if a page-fault is needed. I wish there was a simple: TEST MEMORY AND BRANCH INVALID operands R1 is a register pair with R1=address and R1+1=length to validate. (Like an MVCL.) Instead of a SOC4, just branch to the address provided as the second operand where I have placed an error handler. Tony Thigpen Paul Gilmartin wrote on 3/5/22 16:48: On Mar 5, 2022, at 05:44:41, João Reginato wrote: Which is the best instruction to test if a virtual address is still valid to avoid an unexpected S0C4? How is that information useful? Is its usefulness diminished by "an unexpected S0C4"? -- gil
Re: Fun with RXSBG
To paraphrase the Great and Powerful Oz, "Pay no attention to that man behind
the macro."
I had made a bunch of clean-up to this macro, renaming operands to be more
meaningful, and mistakenly sent out a partially-updated copy. A fully-updated
copy is attached. I cleaned up the MEXIT and &A errors and also added a few
comments indicating that general register 0 shouldn't be used for the pointer
or length, and dropped the fifth operand off the RISBGT instruction (since it's
optional and defaults to zero).
MACRO
&LABEL WIF &P=1,&L=,&C=,&S=0,&OK=,&NFG=
.*
.* Will It Fit?
.*
.* Given the following:
.* 1. Register "P" pointing to the next available location in an
.* integral buffer (i.e., the size and alignment are a power of
.* two);
.* 2. Register "L" containing the length of a prospective object to
.* be added to the buffer; and
.* 3. Characteristic C, where C represents the integral boundary as
.* a power of two;
.* Will the prospective object fit within the buffer?
.*
.* Operands:
.* P:Starting address; default is general register 1.
.* L:Length of object in a general register; no default.
.* C:Characteristic (i.e., power of two) representing the
.* integral boundary (e.g., C=8 means a 256-byte boundary).
.* S:Scratch register; default is general register 0.
.* OK: Branch location if the object fits; no default.
.* NFG: Branch location if the object does not fit; no default.
.*
.* A PSW condittion code of zero indicates the object fits, and may be
.* used in place of the OK and/or NFG operands.
.*
.* Note: For proper operation, both P and L should designate a general
.* register other than 0.
.*
AIF (&C GT 64).BAD_C
&LABEL LAY &S,-1(&L,&P) Point at last prospective byte.
RXSBGT &S,&P,0,63-&C Carry past boundary?
AIF ('&OK' EQ '').SKIP_OK
JZ&OKNo; prospective object fits.
.SKIP_OK ANOP
AIF ('&NFG' EQ '').SKIP_NFG
JNZ &NFG Yes; prospective object doesn't fit.
.SKIP_NFG MEXIT
.BAD_C MNOTE 8,'C must be between 0 and 63.'
MEND
Re: Testing address validity
On Mar 5, 2022, at 05:44:41, João Reginato wrote: > > Which is the best instruction to test if a virtual address is still valid to > avoid an unexpected S0C4? > How is that information useful? Is its usefulness diminished by "an unexpected S0C4"? -- gil
Re: Long Displacement Facility (was: Fun with RXSBG)
The long-displacement facility has been part of the z/OS architecture level set since z/OS 2.1 (including the "high performance" variant). Mark B wrote: If you need to test a facility bit in the range of 0-31 then use the list of bits stored by the STORE FACILITY LIST instruction, which should have been placed in some common location by the OS you're running on, typically at location x'C8'. If you need to test a facility bit >=32 *and* you might possibly be running on a pre-z9 machine(!) then first test bit 7 of the result stored by STORE FACILITY LIST to see if STFLE is available, and if it is then issue the STFLE instruction (if the output isn't already available somewhere) and test the bit from the list of bits stored. For z/OS, the IPL-time output is "already available somewhere". If you are interested in the IPL-time state of facility bits (which in almost all cases is what you would care about), as opposed to the state "now": * For any bit in the first 256, you can look at the area located by x'C8' (FLCFACL/FLCFACLE in IHAPSA, or FlceFactilitiesList/FlceFacilitiesList1 in IHAPSAE). * For any bit at all you can look at the area mapped by IHAFACL and pointed to by ECVTFACL (you can also use IHAFACL to look at the PSA area, with a little manipulation to account for the header of the area pointed to by ECVTFACL) Peter Relson z/OS Core Technology Design
Re: Testing address validity
Just curious would the following macros work better as a replacement for TPROT in the requested case? IARBRVER, IARBRVEA, and IARBRVKA Regards, Jeremy Schwartz From: IBM Mainframe Assembler List on behalf of Philippe Leite Sent: Saturday, March 5, 2022 9:28 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity CAUTION: This message was sent from outside the company. Do not click links or open attachments unless you recognize the sender and know the content is safe. You can use TPROT for this purpose but it's a privileged instruction. Regards, Philippe Leite LAB Services - IBM Em sáb., 5 de mar. de 2022 09:45, João Reginato escreveu: > Hi > > Which is the best instruction to test if a virtual address is still valid > to > avoid an unexpected S0C4? > > > > TIA > > João > > > --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email.
Re: Fun with RXSBG
Hi Dan. I believe you have run into a couple of glitches in the z390 assembler. There is another issue with your WIF macro. The line: &LABEL LAY &S,-1(&A,&P) references variable symbol "&A" which is not defined. The HLASM Language Reference states: : Use the MEND statement to indicate the end of a macro : definition. It also provides an exit when it is processed : during macro expansion. It can appear only once within a macro : definition and must be the last statement in every macro : definition. That last sentence in the IBM doc snippet isn't strictly precise. To try to avoid too many complicating factors, I am intentionally avoiding the discussion of nested macro definitions. Historically, the IBM mainframe assemblers ignore everything following the MEND statement when processing a macro contained in a macro library. IBM has taken advantage of this when producing bilingual (assembler and, for example, PL/X) macros. A simple example of this is macro BPXYENFO. A part of making this work is having a method of telling the alternative language processor (the PL/X compiler in my example) to effectively ignore column one of all lines in the source stream. For PL/I this is the "MARGINS" compiler option: "The MARGINS option specifies which part of each compiler input record contains PL/I statements". When a macro definition is "in-line" with the source stream, the lines following the MEND statement are part of the "open code". Having worked on the development and support of several IBM mainframe assemblers, I can testify that processing source code compatibly is quite challenging; the language rules are not exactly "crisp" nor are they consistent :) But, it is what it is, and the history is long.
Re: Testing address validity
On Sat, 5 Mar 2022 09:44:41 -0300 João Reginato wrote: :>Which is the best instruction to test if a virtual address is still valid to :>avoid an unexpected S0C4? There have been multiple answers regarding a technique. I would question the business case for this. The obvious case is a higher authority routine (SVC/PC-supervisor state/system key eligible) accepting an address on behalf of a problem state program. The code in that case should access the storage using the key of the caller and let the chips fall where they may. Why do you care if there is an abend? If you are writing a storage snooping program, you would need to determine key if the storage can be resolved. Finally, unless the appropriate system locks (MVS) and there is proper disablement, the same query asked a few instructions later may get a different answer. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel
Re: Testing address validity
Several years ago at SHARE, I did a presentation on various requests for new architecture. Such an instruction to determine accessibility was at the top of the list. So, I dragged out an architecture instruction template and designed one on the spot: Given a base register, index register, and long displacement using a standard RXY instruction format, set a condition code to indicate whether the access caused an exception. Oh, plus programming note 1: This instruction is absolutely useless! Upon reflection, my proposed PN#1 was not totally accurate. If you happened to be running in a non-virtual environment such as OS/MFT, things would work just swell. But for any OS that uses paging to present a virtual address space to the user, only the OS knows the answer to this question. So, you need to use an OS service to make the determination. As an alternative to setting up an ESPIE environment, you might want to consider transactional execution (TX, available on the z12 and up). In addition to its multiprocessing lock elision features, TX also provides an easy means for an application to do speculative execution by evading certain program-interruption conditions. For example: TBEGIN TDB,2 JNZ ABORTED ... speculatively access data. TEND If the code branches to the ABORTED label, a transaction diagnostic block is stored (except for CC1), and the program can determine what exception condition caused the abort and whether recovery is likely without OS intervention. See the TX section of Chapter 5 for more details.
Re: Testing address validity
And I would say that ESTAE is "heavy" and is not the best choice if you expect the S0C4 with some frequency, but ESPIE is "light" and intended for this sort of thing. I remember there was some sort of VSE -- DOS/360 when I was using it -- equivalent. STXIT? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ed Jaffe Sent: Saturday, March 5, 2022 8:36 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity On 3/5/2022 7:28 AM, Philippe Leite wrote: > You can use TPROT for this purpose but it's a privileged instruction. Not only is it privileged, but it does not do what the OP has asked for. He is not concerned only about storage that happens to be paged in, he wants the answer for storage that is paged out as well. Even if such an instruction did exist, there are timing window issues -- as Charles Mills correctly pointed out. The only foolproof method is to use a recovery routine: e.g., ESPIE, ESTAE(X), ARR, FRR in z/OS or whatever equivalents exist in other operating system environments like z/VSE, z/VM, z/TPF, Linux on Z, etc. -- 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.
Re: Testing address validity
On 3/5/2022 7:28 AM, Philippe Leite wrote: You can use TPROT for this purpose but it's a privileged instruction. Not only is it privileged, but it does not do what the OP has asked for. He is not concerned only about storage that happens to be paged in, he wants the answer for storage that is paged out as well. Even if such an instruction did exist, there are timing window issues -- as Charles Mills correctly pointed out. The only foolproof method is to use a recovery routine: e.g., ESPIE, ESTAE(X), ARR, FRR in z/OS or whatever equivalents exist in other operating system environments like z/VSE, z/VM, z/TPF, Linux on Z, etc. -- 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.
Re: Testing address validity
Also, the question is somewhat unanswerable without knowing the environment. z/OS? VSE? CMS? Non-privileged program? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Saturday, March 5, 2022 7:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity I think VSMLOC may do the job for you. But all it can tell you is that the storage is allocated at the time of the VSMLOC, not what it might be a microsecond later when you access it. THE BEST thing is to set up an ESPIE and recover from any S0C4. ESPIE is lightweight. This is exactly what it is intended for. (Or SETFRR if more appropriate to your environment.) Really an IBMMAIN question. Not really about the assembler language. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of João Reginato Sent: Saturday, March 5, 2022 4:45 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Testing address validity Importance: Low Hi Which is the best instruction to test if a virtual address is still valid to avoid an unexpected S0C4?
Re: Testing address validity
I think VSMLOC may do the job for you. But all it can tell you is that the storage is allocated at the time of the VSMLOC, not what it might be a microsecond later when you access it. THE BEST thing is to set up an ESPIE and recover from any S0C4. ESPIE is lightweight. This is exactly what it is intended for. (Or SETFRR if more appropriate to your environment.) Really an IBMMAIN question. Not really about the assembler language. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of João Reginato Sent: Saturday, March 5, 2022 4:45 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Testing address validity Importance: Low Hi Which is the best instruction to test if a virtual address is still valid to avoid an unexpected S0C4?
Re: Testing address validity
You can use TPROT for this purpose but it's a privileged instruction. Regards, Philippe Leite LAB Services - IBM Em sáb., 5 de mar. de 2022 09:45, João Reginato escreveu: > Hi > > Which is the best instruction to test if a virtual address is still valid > to > avoid an unexpected S0C4? > > > > TIA > > João > > >
Testing address validity
Hi Which is the best instruction to test if a virtual address is still valid to avoid an unexpected S0C4? TIA João
Re: Long Displacement Facility (was: Fun with RXSBG)
>> IHAFACL uops - I spoke too soon Am 04.03.22 um 19:44 schrieb Philippe Leite: Macro IHAFACL Regards, Philippe Leite LAB Services - IBM
Re: Long Displacement Facility (was: Fun with RXSBG)
and for the VSE people around z/VSE stores facility indications beginning at V=R location 200 (C8 hex), so you don't have to issue these instructions yourself.) and to IBM people supporting this: wouldn't it be nice to have a copy book such that you can simply code: TM my_feature_of_interest,L'my_feature_of_interestis my fav feature installed as it is with the copy-book for ADATA Martin Am 04.03.22 um 19:08 schrieb Dan Greiner: The presence of the facility is indicated facility indication bit 18 (facility installed) and bit 19 (facility installed in hardware) as stored by the STFL and STFLE instructions. (z/OS programmers take note: z/OS stores facility indications beginning at V=R location 200 (C8 hex), so you don't have to issue these instructions yourself.)
