On Thu, Jan 4, 2018 at 12:26 PM, Charles Mills <[email protected]> wrote:
> My very amateur reading of the paper is that it affects fetch-protected > memory that is otherwise addressable by the intruder. So my wild guess is > that it would affect fetch-protected common storage on any Z OS, but would > not allow an intruder to read data in another address space. But my degree > of certainty on the above analysis is very low. > I have a "name" for a programmer who puts sensitive information into z/OS "common" storage. But it would make your LCD screen explode and then melt. Personally, if I needed to keep a password, or other sensitive information: (1) it would never be "in the clear" and (2) the encrypted value would be held in either my address space or a SCOPE=SINGLE data space. If "somebody else" needs to "use" the data somehow, it would invoke the accessor routine via a PC-ss instruction. Of course, this is a lot of "overhead" and would likely cause upper level management to explode in rage and force me to put it in key 8 CSA unencrypted for "ease of use". And yes, I've heard of things like this (not exactly this) being done. > > Charles > -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
