> I happened to be browsing PoOPS for another reason and noticed that > TPROT is a privileged instruction. Reading the instruction details > I couldn't really see any particular security exposure that could > result from TPROT being usable in a non-privileged mode by > unauthorized programs. > > Reading about TPROT led me of course to IVSK, which is needed to > extract the access and fetch bits for the block of storage to be > tested with TPROT. Same question there, why is it privileged? It > would seem that it is privileged because it is subject to the > extraction-authority control, bit 36 of control register 0, which > can obviously only be set by a privileged program like the operating > system code. > > But why protect IVSK so closely (and probably by implication TPROT)? > It would seem to me to be an obvious boon to careful programmers > willing to code tests of their input argument addresses to verify > that those addresses can be fetched from, and possibly also for some > argument addresses whether they can be stored into. > > I really can't see the security exposure here. Can anyone explain > the privilege requirement to me?
In VM/370 (that is, prior to the invention of SIE in the 370/XA architecture), VM guests always ran in real problem state (even when they were in virtual supervisor state), so that VM could use the privileged-operation exception to intercept instructions which it needed to virtualize. TPROT was certainly an instruction which VM needed to intercept. After SIE in 370/XA, VM would no longer have needed to restrict TPROT to supervisor state. But we would have no way of knowing what other programs might have depended on it. Prior to BAKR/ESTA and EPSW, a program which wanted to determine whether it was running in problem vs. supervisor state might have issued a privileged instruction to see if it caused a privileged-operation exception (which it could intercept in an ESTAE). If the program happened to have chosen TPROT for that purpose, and TPROT had been changed to allow problem state use after SIE came along, that incompatible change to TPROT would have broken the program. I am not aware of any security reasons for restricting TPROT. As someone already posted, z/OS always turns on CR0.36, thus always allowing IVSK in problem state. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
