On Mon, Mar 30, 2015 at 8:07 AM, Paul Gilmartin <0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 30 Mar 2015 06:54:57 -0500, John McKown wrote: > > >>To me, one of the biggest pluses is the "hardware memory key". As now >>used by z/OS, it really helps with reliability because, properly used, >>it enforces separation of authority (ability to write) by major OS >>subsystem. E.g. JES2 code can't step on VTAM memory in common >>storage. >> > Certainly an effective accommodation to the single address space limitation > of its time. but consider the gyrations the TSO TMP performs to run > a mixture of privileged and unprivileged tasks in a single address space. > (It might be better if all authorized programs had the discipline to > obtain storage only in system key and unauthorized were restricted to > user key, and if instead of JSCBAUTH there were a similar flag, but > with TCB rather than job step scope so subtasks could be dispatched in > suitable PSW keys. Alas, no one anticipated,)
Well, with APF code, you could create a new JSCB to be used with the ATTACHX macro. The new JSCB would be associated with the new TCB and have the JSCBAUTH bit OFF. Unfortunately, this still has a security hole due to the fact that the APF code and the non-APF code are running in the same address space and likely both going to be running in key 8. And so the unauthorized code could possibly corrupt (perhaps maliciously) the memory of the APF code, causing it to "do bad things". This is one main reason why I prefer the UNIX fork() philosophy rather than "threading". At least when the other code is not under my personal control. Too bad that creating a new z/OS address space is so expensive compared to something like Linux. Of course, one reason is due to the fact that a z/OS address space has a lot of system level TCBs set up inside it before the user code is even looked at. Which explains the use of the BPXAS "UNIX initiator" address spaces. > > Nowadays, isn't segment protection with multiple address spaces a better > approach? That doesn't protect memory in COMMON storage such as ECSA. It is significantly better than MVT's use of different keys 1..15 to separate memory for regions in real memory. Of course, IBM has done some really good things to reduce use of COMMON storage, such as dual address space, and especially AR mode. But I still like the isolation of protect keys. Maybe I'm just old fashioned in this regard . > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
