With respect to your last paragraph, I am not arguing. I am stating facts.
1. z/OS System Integrity requires that modules which execute in authorized state and are addressable by unauthorized programs must be protected from modification by unauthorized programs, z/OS is designed to satisfy this requirement by using key 0 storage for Nucleus, LPA, and load modules and program objects in APF-authorized libraries that have the RENT attribute. Developers of modules which execute in an authorized state are required to understand this and use these techniques where needed to ensure that their modules conform to this requirement. You are free to have the opinion that using the RENT attribute for this purpose by the MVS designers over 45 years ago was a perversion of the definition of RENT, and that they should not have done that, and possibly used REFR or created a new attribute for that purpose. And I might be inclined to agree with that opinion. I expect that they had pragmatic development cost reasons for doing what they did, and regardless of the reasons, we are stuck with remaining compatible with that, because compatibility is one of the things that keeps z/OS in business, and we like to stay in business. 2. z/OS is not required to protect programs from modification by programs running in an authorized state, However, for system reliability, availability, and serviceability reasons, we find it to be very useful to do so where possible. That is why LPA has been DAT-protected since MVS SP1.3 on enhanced 3033 machines, and why the read-only nucleus has been DAT-protected since MVS/XA, and why I experimented with the possibility of DAT-protecting RENT modules, and ended up implementing REFRPROT. You are free to have the opinion that using the REFR attribute for REFPROT was a perversion of the definition of REFR, and I won't argue against that. We are constrained as always by pragmatic development cost considerations. Such is life in software engineering. Creating a new attribute would be more expensive. and we have space constraints in the PDS directory entry, and getting exploitation by rebinding a lot of things with a new attribute would be expensive, and there were already quite a few things that are bound with the REFR attribute, which provided zero-cost exploitation. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" <[email protected]> wrote on 09/03/2021 10:05:13 PM: > From: "CM Poncelet" <[email protected]> > To: [email protected] > Date: 09/04/2021 01:21 AM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" <[email protected]> > > At the risk of inviting 'flak', I suspect that there is a misconception > of what RENT and REFR modules actually are. > > By definition, RENT and REFR modules should never modify themselves > (excluding the peculiar case of a RENT module that ENQ's on part of its > code, modifies it, restores it to what it was, then DEQ's it - as this > would not violate the definition of RENT modules being concurrently > executable by multiple tasks.) > > A module is REFR or RENT - not if it is link-edited as REFR or RENT, but > if it never modifies its own storage. In other words, all modifiable > storage must first be GETMAINed (including the module's savearea > storage) and any WTO(R)s and DYNALLOC/SVC-99s, DCBs, ACBs and/or RPLs > etc. must then use the 'list' and 'executable' forms of these > macros/DSECTs to avoid modifying the module's own storage.) > > As a 'first line of defence', such modules should be coded as RSECTs and > not as CSECTs - and the assembler will then trap (with a CC=08, IIRC) > any direct attempt to modify the module's own storage. But it is the > programmer/developer who is responsible for ensuring that the module's > code is indeed REFR or RENT - and it is not the linkage-editor or > binder's responsibility. > > Arguing that REFR or RENT modules need to be 'protected' from modifying > themselves, or by others, is methinks beside the point - because such > modules should have been coded in such way that they *never* modify > themselves to begin with. If others can modify them, then it is these > other modules that should be investigated, not the REFR or RENT ones. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
