On Tue, 17 Mar 2015 13:01:42 -0500, John McKown <[email protected]> wrote:
>Now that I think on it, one could "mess up" the "rogue" programs >attempts to modify an RSA by deliberately messing up the savearea >chain pointers in the save area pointed to by TCBFSA to defeat forward >save area chaining (perhaps copying the values in that area somewhere >else and setting all 72 bytes to x'00'), setting R13 to some page >boundary GETMAIN'd storage (get 8K and page protect the second 4K >using PGSER), doing the SYNCHX setup previously mentioned, and >restoring the save area chain pointers and restoring the FSA values >after the SYNCHX returns. Of course, this does not stop a "rogue" from >modifying key 8 storage. It just makes it more difficult to find >something "interesting" to modify. In fact, if there are critical >areas which are key 8, GETMAIN them on page boundaries in page >multiples and use PGSER to mark them read-only before the SYNCHX and >then read-write afterwards. Again, this is not impossible to get >around. But it adds another level of coding to the rogue program. But TCBFSA points to one of the more interesting areas for the rogue program to modify :) Yes, you can build in a little more protection by having the main program simply issue SVC 3 rather than restoring registers and branching to R14. But there are probably lots of other key 8 areas you'd still need to worry about. So it's really not a bullet-proof solution. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
