> > I can't believe how often the old chestnut about running in key zero versus > > user ket comes > > up. There is nothing inherently risky running in key zero - presuming of > > course that you're > > not a cowboy coder who fails to validate input and output areas. > > Or a coder who's convinced all bugs in his code have been found, or > perhaps that he never writes bugs in the first place. Probably doesn't > need to test his code either.
there is a big gap between being convinced "all bugs have been found" and coding defensively and with an appropriate degree of care about where inputs come from and where you store results. My point is that a properly working program doesn't make random stores into unintended places, regardless of what key it is running in. The fact that a key zero program could store anywhere but into a store protected area is a red herring. > > Store instructions only go where you point them. The overlay bogey is > > shorthand for > > sloppy coding. > > Uh huh. It certainly reduces the number of S0C4s if you aren't > bothered by pesky restrictions on where you can store. Used to be even > fewer many years ago before we got things like low storage protection > and page protection. again, not my point at all. Properly working programs don't do that. The SRB environment is harsh and unforgiving. Has been since the year dot. Most SRBs run entirely in key zero. That's the way the OS gives them control. Running them in a non-zero system key might in general be a little "safer" for the paranoid and/or careless, particularly for long running enclave SRBs. Although that's (IMO) just as likely to turn up just as many cases where the programmer trips over fetch protection of inputs and/or key protection of stores/moves and, unless you've got decent recovery in place, you don't even hear about it. However, running SRBs in a user key tilts the balance of risk strongly into negative territory if the SRB actually uses user key storage and/or work areas because they can be overwritten by other user key programs. And there's no need to run in user key to (safely) fetch data from a user key area (that's what MVCS/MVCSK etc. have provided forever) and no need to run in a user key to move data into user key storage (MVCS/MVCDK etc). I claim that running ANY supervisor state program in key 8 is far more dangerous than running a well behaved supervisor state program in key zero. Maintaining integrity is a pesky thing and simply running in user key doesn't help you much, if at all. > > As for running in key 8 in an SRB, it is certainly NOT necessary (there are > > mixed key > > instructions for safely moving data to/from caller storage) and furthermore > > it is actually a > > bad idea for a number of reasons. First, it is a fairly unusual condition > > for an SRB to run in > > - potentially causing serious astonishment (I.e. Generally a bad idea) in > > called code, > > So the SRB-mode code should run in key 0, since it won't have bugs > (unless written by a cowboy), but the called code (presumably also SRB > mode) may be "astonished" by its caller's not being in key 0. (Not, I > understand, that *it* may receive control in a non-0 key, but that > it's going to poke around and be dismayed and confused when it sees > that the *caller* wasn't running key 0). Calling anything in any condition other than what it's documented interface specifies is in itself an error, regardless of whether or not it appears to work. Most services that accept SRB mode callers are likely to be making some strong assumptions about the interface and the environment in which they get control. All I am saying is that I wouldn't do it. Ever. > > For the record, I have never once run an SRB in anything but a system PSW > > key, and > > wouldn't. There's just no reason to > > Have you ever had occasion to run *someone else's code* (maybe that > kind that would be surprised and upset to get control in the wrong > key) in SRB mode? Nope.
