MVS can not run on any machine that had an ASCII bit in the PSW. There was no statement of integrity for OS/360.
Does anybody know whether there was a statement of integrity for RSS/360? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Charles Mills <[email protected]> Sent: Saturday, August 8, 2020 7:53 PM To: [email protected] Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) I am not suggesting anything nefarious or in violation of the Statement. A program that is linkedited (sorry, I just can't get used to saying "bound") with AC=1 and stored into an APF-authorized library -- all documented and above-board and under the customer's control -- can issue MODESET MODE=SUP and get into supervisor state. In addition, various "user" exits run in supervisor state. As do appendage routines IIRC. Etc. APF-authorized products may have PC routines that run in supervisor state. The point of my post was not "oh, z/OS is full of holes." It's not AFAIK, and I did not mean anything of the sort. My point was that there might have been code somewhere that set the ASCII bit on, even if the IBM OSes did not offer a "MODESET SIGN=ASCII" macro instruction. There are several ways that customer or vendor code may have done so in addition to "magic SVCs." And yes, before someone else points it out, my memory of the history of the platform is not perfect. Exactly which of these methods were available back when the ASCII bit was still around is not something that is at the top of my stack. Certainly magic SVCs were less out of fashion back in those days. I would have to think this through, but right off it would seem to me that a semi-magical SVC that did only one thing -- toggling the ASCII bit for its caller -- would not violate the integrity of the box as a whole. There could be some factor I have not thought of; this is an off-hand speculation of moot significance, not a statement to give to your auditor. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Saturday, August 8, 2020 2:53 PM To: [email protected] Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) On 2020-08-08, at 15:19:05, Charles Mills wrote: > > Or a dozen or more other non-magic ways of getting into supervisor state. > How does this interact with IBM's Statement of Integrity: https://www.vm.ibm.com/devpages/SPERA/istatmnt.html ... IBM will accept all APARs that describe exposures to the System Integrity of MVS ... System Integrity is defined for MVS as the inability of any program not authorized by a mechanism under the customer's control to: • circumvent or disable store or fetch protection • access an OS password-protected or a RACF-protected resource (RACF is the Resource Access Control Facility), or • obtain control in an authorized state; that is, in supervisor state, with a protection key less than eight (8), or Authorized Program Facility (APF) authorized. Of course, "under the customer's control" is a key phrase.
