In Unix, we would probably use ptrace(), which is a debug facility. One can easily stop a program(process), modify memory or anything else in the program address space, then restart the program with it being none the wiser.
-Paul On Nov 17, 2014, at 11:46 AM, "Farley, Peter x23353" <[email protected]> wrote: I would presume that a mechanism that permitted an ordinary programmer to create and access his/her own address spaces would automatically limit any access to the initial address space (batch/TSO/Unix) and any address spaces created from it, and prohibit access to address spaces not created by the originating address space. The programmer ought to be able to write and use PC-ss code to perform functions in any of the self-created address spaces, and thus be able to create and test viable client/server programs to perform any envisioned business function. Authorized programs and privileged instructions ought not to be required to build such systems. Accessing address spaces you did not create (i.e., "spying" in other user's address spaces) is not what I imagined or desired. Any such "spying" capability (and much more so any mechanism permitting modification of contents) must of course come with authorization requirements for the security and integrity of the whole system. But who does it hurt if I bollix my own self-created address spaces? That should have no more impact on the entire system than bollixing my own task does now. There are other hard questions, like how to limit how many such address spaces can be created by any one user to prevent "runaway" space creation and virtual page disk space exhaustion, but these are more properly answered by control mechanisms in the operating system, not in the hardware. How to design such a hardware environment is well beyond my capabilities, so I will not try to directly answer that question. I was merely pointing out that I thought that the hardware design which IBM created was not an ideal one from the standpoint of the ordinary (but sophisticated and experienced) application programmer. Not that I expect any of the current design to ever change of course. It is now written in stone. Unix programming "fork" capabilities, shared memory objects and mutex signaling mechanisms provide some of the functional capabilities I described above, but not the full range of course. Peter
-----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER- [email protected]] On Behalf Of Tom Marchant Sent: Monday, November 17, 2014 10:06 AM To: [email protected] Subject: Re: Redesigning the Principles of Operation Manual On Fri, 14 Nov 2014 18:31:23 -0500, Farley, Peter x23353 wrote: >I have often thought it was a mistaken design by IBM that prohibits >non-authorized programmers from exploiting multiple address spaces >and instruction-level space-switching facilities. How would you propose that such non-authorized programs access only the other address spaces that they were permitted to access? In other words, how would you protect the integrity of all address spaces if unauthorized code were able to access other address spaces? -- Tom Marchant
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
