I believe that with REFRPROT, a 5KiB module with RENT will be loaded into two pages both of which are page protected.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Joel C. Ewing [[email protected]] Sent: Sunday, August 29, 2021 7:23 PM To: [email protected] Subject: Re: RENT binder option If REFRPROT is used, the affected module is loaded into a key-0 storage pool, so even if a partial page at the end of the module is not "page protected", it is still key-0-protected and only a program running in key 0 can modify it. A program running in key-0 that could directly modify the final partial page could also in theory page-fix any of the full pages of the module, bypass any "page protection" and update a protected full page as well, so if you allow malicious programs to run in key-0, as always all bets are off. Since deliberate malicious modification by key-0 code is always possible, this partial page additional exposure is probably minimal. If you wanted to rule out the possibility of any accidental modification by key-0 code of the entire module, the simplest solution would be to force the length of REFR modules to a multiple of 4KiB so there are no partial pages. Maybe this size rounding should be an option for REFR modules now that real-storage and virtual-storage constraints are less of an issue for many installations. Joel C. Ewing On 8/29/21 5:59 AM, Lennie Dymoke-Bradshaw wrote: > 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://secure-web.cisco.com/1NLk9V3hjcFNgG5yDTKUzJ7MMYjPWfVOXbh9pmBJmYPAWtUsU8O3yKS6Qnp31A7uj0iKtP3bUftowH7LdTjtNu026EqE_5oa5FD2zUi5vnEIou_uesNvX2wKo5izNuD3daV5dAq6OL6ETajAVIpZxKNlpOZJpl9tV206FBvIP0VXbxQE1Rbm8c9b495qFqEPWKH948RvvGeRP61mA3nVorH6z-wh48-PZt1F1jRQ8ogjND-dmVwFmFdx3Pr46k7VWjw6m-jNVx0w5spKChr9g_92n1m5hNhVbQk70N291DDHu7pT-cwSbFuZ5hw85i4IAfaaSXm5aMneq9UIMWf2e9OPqwU487PKoEQWNtOmdc6_y4Ug0dfujRHlGhIs-xrems9KYt8NaEvFpVj2PdISp3E4luDHhtc0qm4ab5OQL_3x5N1dkBtDpkyVRD1EyR78U/https%3A%2F%2Frsclweb.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 -- Joel C. Ewing ---------------------------------------------------------------------- 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
