On Thu, Aug 27, 2009 at 6:29 PM, Peter Relson <[email protected]> wrote:
> There is no subpool that would satisfy both of the following > -- work for unauthorized callers running in their state and key > -- work for authorized callers running in their state and key and not come > out of "low private" (where "low" refers to the user region, not to "below > 16M") > > So it's at least not simply a matter of subpool choice (since "low > private" is usually a concern for an authorized application). > > Yes, of course, an application could at runtime select which subpool to > use. > > This thread had made me think about this a few days ago. > > I wonder if they happen to use subpool 0 which might, at least, let a key 0 > invocation work (as it would be translated to subpool 252; I can't remember > if that also requires supervisor state) Privileged progams are responsible for making conscious informed choices about the subpools. The translation to/from SP252 for naieve callers taking the (SP0) default has been around longer than I have. But I doubt very much that that would even help in this case. The interface specification for the API says... * Enabled for I/O and external interrupts * Holds no locks * In task control block (TCB) mode * With PSW key equal to the job step TCB key <=== Here's the first clue something is wrong * In primary address space mode * In 31-bit addressing mode * In either supervisor or problem program state <=== And here's the second clue * With no FRRs on the current FRR stack. The doc goes on to say immediately after that; "You can call the binder in both problem program and supervisor state and in any PSW storage key." The last statement appears to contradict the statement in the interface definition, nevertheless as you are aware that statement is quite problematic for privileged programs. The PSW key must match the job step task's key - I believe that the requirement is specified this way because load modules and program objects are step level resources and the binder uses a low private step level subpool during processing. But they also say the caller can be in supervisor state... and the only way that could be a safe thing to do would be in an address space with an APF authorized job step task, or in an address space with a system protection key specified via PPT. The more prosaic case of a piece of (privileged) infrastructure code performing a service on behalf of a completely non-privileged program appears to me to be ruled out on integrity grounds despite the ambivalence in the wording of the documentation. I believe that the API was written in a completely naieve fashion much like any other batch program and certainly without any thought to properly handling the nuances presented by a privileged caller in an otherwise non-privileged environment. Given that, we elected not to persevere with using it. However, just to be crystal clear. These deficiencies of the API were only the final icing on the cake. The real deal-breaker is that the multipart class architecture of PM3 (as currently implemented) is unusable at all. So even if the binder API were to be refactored at some time in the future to behave like any other well formed system service, the result would be moot. CC -- 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: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
