Walt, You are absolutely right! If I needed to consider the "general case," I would absolutely want to do things differently (being invoked from a user-coded exit comes to mind as one such case). However, in a more tightly controlled environment, guarantees are indeed easier to come by.
In responding to the OP's "what do you do?" solicitation, by no means did I intend to offer a general recommendation. Thank you for pointing out a very important consideration. Regards, Doug The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Walt Farrell Sent: Wednesday, August 11, 2010 1:44 PM To: [email protected] Subject: Re: Parameter passing: overly cautious or properly paranoid? On Wed, 11 Aug 2010 10:39:50 -0400, Watkins, Douglas <[email protected]> wrote: >When creating new routines, I prefer they be created in an "API-style," >using macros for generating the parameter list and invoking the routine >as well as mapping the list of pointers and the fields to which they >point. This gives the called routine a relatively high degree of >confidence that the construction of the parameter list is valid. While I may agree with providing that method of constructing the parameters and invoking the module, I would say that from a system integrity point of view the called module still must verify everything. In the general case it can not assume that the caller used the method you provided. In other words, you might have a "relatively high degree of confidence" that the parameter list is valid if you can guarantee that you wrote all the code in the callers, too. But if you can't guarantee that, you have a false sense of confidence that might well lead you to having an integrity exposure. -- Walt Farrell IBM STSM, z/OS Security Design
