I appreciate everyone who contributed to this long tangent from the original problem. What was meant by controlling execution of instructions only became evident as the dialogue continued. It appears that the control is achieved by methods similar to my use of z/XDC under z/OS and other assembler level debuggers (including those that use the TRAP z/Series hardware instructions).
Although we may have serious reservations about the efficiency of using those techniques to control normal program execution, I know there were IBM customers who ran MVS under VM before it was optimized and experienced extremely onerous levels of overhead. It was not that long ago when it seemed that running Java on a mainframe was in that range of overhead. And almost every time I use REXX instead of assembler I probably magnify my CPU and elapsed times similarly. I would suggest that, now that we know it is implemented in software, this form of controlling instruction execution is not that rare and is as foolproof as the creators of the software (whether ptrace(0), Java VM's, z/XDC, etc.) are able to make them. And whether we'd ever use them in a production environment probably has more to do with auditors and managers and hardware capacity than our personal feelings about their advisability. Gary Weinhold Data Kinetics, Ltd. Paul Raulerson wrote:
(I think the copied text to this is mangled by this interface, though it looks okay here. If so, sorry.) Juding by your commentary, I can only assume you have not used ptrace() to completely control execution of a program, including examining the current instruction, and modifying memory. This is quite easy to do. Or is it that I am not being clear? You cannot do so *within the subject program* - you have to do it from a separate process, such as a dispatcher or whatever you wish to use. You can certainly do so with fairly easy to understand kernel modifications. Part of this misunderstanding must be because I am thinking in Unix terms, and you are thinking in z/Series terms. I do not think any of the process control in z/Linux is determined or dependent upon z/Series Arch, though I may be wrong there. Even on a common xSeries machine, you can do exactly the same thing. Obviously, some of the issues one runs into are complex. For example, you take an execution hit because you defeat a lot of pipelined execution, and other very serious instruction set execution optimizations. I am not sure if this is what you are thinking of or not, but regardless, it doesn't make much difference. As you, or someone else mentioned, you can also "sandbox" the entire execution if you wish, using either virtual machine or emulation techniques or simply by compiling to some form of byte code and having the execution engine restrict what it will allow to be executed. Again, fairly standard techniques that have been in place for quite a while. Building an environment where you control what instructions are executed is not a new, radical, or even very technically challenging thing. And to tie this back, z/Linux does not allow certain semi-privileged instructions to be executed in user mode, even if you are running with root privileges. Originally I wondered if the user had encountered one of these issues, but was quickly apprised that was not so. And as I said, I have no trouble assembling or executing the instruction here. I have not tried to assemble it with the gas assembler, as I just don't like the thing. However, I just tried it and it does not seem to generate the correct code. I think. This is what gas generates: 20 ???? A7180000 lhi%r1,0 21 ???? 1821 lr%r2,%r1 22 epsw %r1,%r2 23 ???? 98BFB09C lm%r11,%r15,156(%r11) And this what HLASM generates: 00000076 B98D 0012 85 EPSW R1,R2 -----Original Message----- From: Tony Harminc [mailto:[email protected]] Sent: Wednesday, July 14, 2010 10:43 AM To: [email protected] Subject: Re: z Linux assembler relative or friend or foe? On 14 July 2010 10:06, Paul Raulerson wrote:> On Jul 13, 2010, at 5:19 PM, Rob van der Heij wrote:>>> On Tue, Jul 13, 2010 at 7:55 PM, Tony Harminc wrote:>>>>> Linux may well have facilities that I am not familiar with to scan>>> modules for certain byte sequences, but any such static scan is going>>> to be easily foolable by even a slightly motivated programmer. Linux>>> could in theory, but we know does not in practice, interpret most>>> programs at run time, and thus catch any behaviour it doesn't like, at>>> an extreme cost in performance. What it cannot do is alter the>>> architecture of the machine it is running on in violation of the>>> Principles of Operation.>>> Not at all.Not at all what? You *can* violate the Principles of Operation using Linux?> Look up ptrace(). This was built into Unix as part of process> control more than 30 years ago. I do not have time to go into a long discussion> right now, but do realize that Unix / Linux is a full operating system.I !
am reasonably familiar with ptrace(), and to my knowledge itprovides no facility for instruction interpretation or screening. Theptrace() facility is the kernel infrastructure for debugging tools.You can set breakpoints, capture kernel events related to the debuggedprocess, and so on. Breakpoints on all architectures are set byoverlaying the target instruction with an appropriateinterrupt-causing value, such as an SVC on zArch. This does not allowyou to capture the execution of an unprivileged instruction that youdon't know the location of in advance.Again we have digressed into talk of malware and root privs and such,but the original claim was that Linux can somehow "limit" theexecution of certain unprivileged instructions, specifically EPSW.Please explain how you would go about this. How about if I write aprogram that issues an EPSW instruction, and you run the program suchthat it otherwise runs normally, but fails to execute or in some sense"traps" on that instruction?To! ny H.
