On Tue, Mar 17, 2015 at 12:10 PM, Paul Gilmartin <[email protected]> wrote: <snip> > Sigh. Cf. UNIX, which certainly doesn't let exit() branch to a > user-modifiable address. > A better designed END SVC would branch, not to the R15 in a key 8 RSA, but to > a > caller's address kept in protected storage.
SVC 3 (EXIT) does not return to R15 in the RSA, but (I think, likely more) (1) makes the previous RB the "current" RB, (2) releases the exiting RB's storage, and (3) restores the PSW and registers from the contents of the now current RB (what was the previous RB at the time that the SVC 3 was issued). 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. > > -- gil -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
