On Sun, Apr 15, 2012 at 12:29 PM, Micheal Butz <[email protected]>wrote:
> I am getting S0C4 04 within a wait which leads me to believe that the > storage key of the ECB storage key is not the same as the PSW STORAGE KEY > 8- 11. Does the following code make sense to resolve this address > > > TESTAUTH FCTN=1 TEST APF AUTORIZATION > LTR R15,R5 CHECK R15 > BNZ NAPF&SYSNDX NOT APF > MODESET MODE=SUP,KEY=NZERO TURN ON BIT 15 IN PSW > LA R0,REPLY_ECB GET ECB ADDRESS > IVSK R1,R0 GET STORAGE KEY > MODESET KEYREG=R1,SAVEKEY=OLDKEY SET STORAGE KEY IN PSW > WAIT=REPLY_ECB > MODESET MODE=PROB,KEY=NZERO back to current TCB key > I'm sorry if I seem to be picking on you but there are so many ways that this is wrong. You don't need to be in supervisor state to issue the IVSK instruction, but that's the least of your worries. Overtly changing to key zero just guarantees that the OS is going to vaporize 4 bytes at what ever location you specify - even if it isn't really an ECB at all. In other words, it is another (data) integrity hole. You should never be using an ECB that is in another key than your current PSW key. The system gives you a way to do it, but it assumes you know what you're doing. The only real exception to this is the stop/modify communications ECB for your your address space. The OS has a special case code path that lets you wait on that. There might be other exceptions when you know what you're doing, but this isn't one of them. So to reiterate my earlier advice, you're going in the wrong direction. If you're going to write privileged code that runs entirely within a single APF authorized address space you can do more or less whatever you want. However, if your code might ever get control in a non-APF environment, or you try to share code/data between address spaces, you have a steep hill to climb to avoid compromising integrity. Sorry, them's just the facts. -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
