True, I oversimplified. Still, if the SVC does not break the normal rules then the SYNCH does not compromise integrity. If it does, then there is an exposure regardless of whether it does a SYNCH.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Binyamin Dissen <[email protected]> Sent: Tuesday, October 15, 2024 7:05 AM To: [email protected] Subject: Re: SVC calling (via SYNCH) a 3GL program Caution: This email did not originate from George Mason’s mail system. Do not click links or open attachments unless you recognize the sender and know the content is safe. The SVC can acquire key8 storage and pass it to the routine via SYNCH. SYNCH RESTORE=YES,KEYADDR=NOKEYADDR(or perhaps =X'90'),STATE=PROB Should ensure getting back good R2-R13 and that the client routine has no SVC related privileges. A SVC should not assume that a key 8 workarea will not be altered from the side, thus it should not store a value and retrieve it afterwards. But it can use the key 8 storage provided by the caller to fetch parameters and return results. On Tue, 15 Oct 2024 10:38:06 +0000 Seymour J Metz <[email protected]> wrote: :>Is the SVC doing something like key 8 storage? Because otherwise none of the issues I can see involve integrity. :> :>-- :>Shmuel (Seymour J.) Metz :>http://mason.gmu.edu/~smetz3 :>??? ?????????? ??? :>?????? ??????????? ???? ?????????? :> :> :> :>________________________________________ :>From: IBM Mainframe Discussion List <[email protected]> on behalf of Attila Fogarasi <[email protected]> :>Sent: Tuesday, October 15, 2024 12:06 AM :>To: [email protected] :>Subject: Re: SVC calling (via SYNCH) a 3GL program :> :>Caution: This email did not originate from George Mason’s mail system. Do not click links or open attachments unless you recognize the sender and know the content is safe. :> :> :>It depends upon what your cobol routine does ... if it issues an SVC :>(generally indirectly, for example by opening a file), then there is a :>potential system integrity issue as an SVC called by another SVC performs :>different checking of its environment than when called by the problem state :>program. This can lead to elevated privileges, which could be a problem. :>Another potential problem is if you statically link LE routines which are :>back-level (or rather, not relinked after an LE upgrade). Cobol code that :>uses no LE services is generally safe, but it is sometimes surprising what :>LE runs and when. :> :>On Tue, Oct 15, 2024 at 2:30?AM Steff Gladstone < :>[email protected]> wrote: :> :>> Thank you Seymour and Binyamin. My LE question was sent before I saw :>> Binyamin's answer. :>> :>> On Mon, 14 Oct 2024 at 18:27, Binyamin Dissen < :>> [email protected]> wrote: :>> :>> > On Mon, 14 Oct 2024 16:53:20 +0300 Steff Gladstone :>> > <[email protected]> wrote: :>> > :>> > :>I hope the following question does not offend the ears (eyes?) of :>> > assembler :>> > :>purists. :>> > :>> > :>Can an SVC call a 3GL program (e.g. COBOL) using the SYNCH macro? Or :>> > must :>> > :>the entire code be pure assembler? We have some fairly complex code :>> > :>already written as a COBOL subroutine and were hoping to recycle it :>> > within :>> > :>the context of the SVC. :>> > :>> > Certainly. :>> > :>> > Though if cleanup isn't done you may eventually run out of storage. Not :>> > sure :>> > how you would clean up the COBOL pieces. But if your initial calling :>> > program :>> > that invokes the SVC is LE you should be fine. :>> > :>> > -- :>> > Binyamin Dissen <[email protected]> :>> > http://secure-web.cisco.com/1gnN46r5RDfHxKFJd6cHrBoguWbyE2VnZbnbfocivMUnUBMBy521QsLNJrRWqTlRYX0XzuAOvi_GXEXhYqVctxuAW5aoLZXKFAkzsz7Q37Xnj8VsBOKnyYoWfAh8uHZ0ddK70UQGXWEeVk39xIukPe3Thw1yC_6s19UgbbHkyylQGA3MJN1weoKcqM6JI0vE-NMx0j1NMMF8DYGDxPQ7Mit8b09Ya06feaLB5ZcFzuBaXe62EgQjZHJbzXfkPZH0A-tWGrvolGSYJjJLB9yS7_mi6GYoi5vk-8uieSLEm6oYbBJjynVgB-qAJOwr74okEEGqaNxvnmRAxZi7-M1VGbgDkPk0YHJjzi2r7YULTtig1SjHHf0rn2jY0h1j7_wLrUCR6gGbFJTqyyDmzGrGr-Q/http%3A%2F%2Fwww.dissensoftware.com :>> > :>> > Director, Dissen Software, Bar & Grill - Israel :>> > :>> > ---------------------------------------------------------------------- :>> > For IBM-MAIN subscribe / signoff / archive access instructions, :>> > send email to [email protected] with the message: INFO IBM-MAIN :>> > :>> :>> ---------------------------------------------------------------------- :>> For IBM-MAIN subscribe / signoff / archive access instructions, :>> send email to [email protected] with the message: INFO IBM-MAIN :>> :> :>---------------------------------------------------------------------- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to [email protected] with the message: INFO IBM-MAIN :> :> :> :>---------------------------------------------------------------------- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to [email protected] with the message: INFO IBM-MAIN -- Binyamin Dissen <[email protected]> http://secure-web.cisco.com/1P9N9YOxMY3Vt05K7gLE96VEAvP9w5tPYT5I4-QwfxJrXHvDD9wUiHRN31i9tt4mU-kT69bW84ypx30vmVstuWEGUoPQS8UIGo7gHtYOx-dUHGC7xP1Lsa5qOwKe3SFlNEyjhh3_eXWNmV-fMC934l6vzw6rCyD8kvnxSkCA_tE4BIm2ufcblMjQ9pKcZ7C732uQ4vhqUGp06P3tLesDan4UVXY65g5-HuIN7TJ-_t_yhz5izQ52Ik8XpkISJp7j0B5jCgJLrzApkQiYIEy8zIxKn8xb3V6FXXYJmEvd_NY4T7jDPvLIPcVo6cTm5zD7PMsxN-ws9whNyssLYtDPwogdomyB16n8ULkraVgHD2WBMLli-u6nZUK54HB3Y6B8awCe7vzjQdLlcVaZ8UGo8ElddJ6Tbv93CdNWSePO1hlg/http%3A%2F%2Fwww.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
