I realise I may be inviting a "YDNRC" but I think the REFRPROT (not REFPROT) option only protects entire pages of a module. If a module is 5K long then the last 1K is unprotected. Always sounded like an opportunity for exploitation; bit like a buffer overrun.
Lennie Dymoke-Bradshaw https://rsclweb.com 'Dance like no one is watching. Encrypt like everyone is.' -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Peter Relson Sent: 28 August 2021 15:02 To: [email protected] Subject: Re: RENT binder option <snip> RENT: MVS protects your module's virtual storage so that your module cannot be modified - and REFR implies RENT. </snip> z/OS ignores "refreshable" except when REFRPROT is in effect. Thus if "REFR implies RENT" then it is important that the RENT indicator be set when REFR is specified without RENT. I presume that that is what happens, but I have not tried it. "cannot be modified" is all a matter of degree. Anything can be modified if you are authorized enough. Some of the rules that apply (the rules are more complex, so this is not completely accurate): -- RENT modules not from an APF-authorized library are not placed in key 0 storage so they "can" be modified by an unauthorized program -- RENT modules from an APF-authorized library are placed in key 0 storage so they "can" be modified by a key 0 program. The same is true for a TCBKEY9 task -- REFR modules with REFPROT are page-protected. When page-fixed, they "can" be modified by using real addresses Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
