OK, I can see where IPK + IVSK for the same address value would provide both fetch and store capability information (given the risk of a state change TOCTTOU) and both are semi-privileged instructions dependent on the extraction-authority control bit, but outside of a truly black-hat usage I can't really see the harm if they were totally unprivileged. Painfully slow if the path length of IVSK is as long as you indicated, but no way I can see to really cause harm to security or integrity, assuming fetch protection has been correctly set in truly sensitive storage blocks.
I do see the need for TPROT in disabled code, which by definition would be privileged anyway. All that an application program might want to know is: 1. Is this address valid in my address space and mode (which I don't usually control or change)? 2. Can I fetch data from this location without causing an abend? 3. Can I store data at this location without causing an abend? TOCTTOU state differences don't usually factor into application storage usage, since the storage that application programmers usually deal with is either valid or it isn't and is either possible to read or it isn't and is either possible to store into or it isn't. For application-level code it is far less likely for a valid address to change state (from the application's POV). Paging exceptions are completely transparent in this usage and only add to elapsed time, they do not affect correct usage of the storage. Avoiding an unnecessary abend is always the goal to avoid affecting SLA's. Reporting an error and skipping the invalid process/record(s) is always preferable to an abend. Thanks for the prompt and insightful reply. Peter -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Chris Craddock Sent: Monday, October 26, 2015 4:01 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Question of curiosity: Why are IVSK and TPROT instrictions privileged? TPROT is definitely privileged. The typical use case is for disabled code to have a non-faulting way of knowing whether storage is backed in memory (and what access a given key would have). TPROT works whether the address is allocated or not. IVSK does not. The result of the IVSK (assuming it was successful) tells you everything you need to know about accessibility from a given key. However, you would NOT use IVSK to get the key of the storage before using it in a TPROT instruction because it would be broadly superfluous and, if you were disabled and the storage wasn't allocated or in memory, you would get a program check on the IVSK anyway. IVSK is only semi-privileged, which means on z/OS you can use it from problem state. Apparently on recent generation hardware IVSK is now a pathlength pig, so you probably ought to steer clear of it anyway. As for why TPROT is privileged ... Back in the day there was at least a fig-leaf idea that problem programs shouldn't be able to "see" certain functions, but there really doesn't seem to be any compelling reason in this case since a non-privileged program could get the same information via a (potentially much longer) path. In all approximately similar cases (IVSK, TPROT, LRAG) there is always the risk that the state of a page may change in between the instruction completing and your usage of the result (TOCTTOU) but for disabled programs (the original use case) the window is pretty negligible. CC ________________________________________ From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> on behalf of Farley, Peter x23353 <peter.far...@broadridge.com> Sent: Monday, October 26, 2015 2:33 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Question of curiosity: Why are IVSK and TPROT instrictions privileged? 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? TIA for helping to cure my ignorance. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
