On Thu, February 9, 2012 01:19, H. Peter Anvin wrote: > On 02/06/2012 05:52 PM, Indan Zupancic wrote: >>> >>> - If the CPU is currently in 32- or 64-bit mode. >> >> What is the best way to find that out at the kernel side? Add a function >> that checks cs and returns the correct answer? But in the kernel path the >> CPU is always in 64-bit mode, so I suppose you want to know what mode the >> tracee was in? >> > > You need to look at the CS descriptor. CS is already available to user space, but any other value than 0x23 or 0x33 will confuse user space, as that is all they know about. Apparently Xen uses different values, but if those are static then user space can check for them separately. But if the values change dynamically then some other way may be needed. But does it make much sense to pass the CPU mode of user space if that mode can be changed at any moment? I don't think it really does. Can you give an example of how that info can be used by a ptracer? > >>> - If we are currently inside a system call, and if so if it was entered >>> via: >>> - SYSCALL64 >>> - INT 80 >>> - SYSCALL32 >>> - SYSENTER >>> >>> The reason we need this information is because for the various 32-bit >>> entry points we do some very ugly swizzling of registers, which >>> matters to a ptrace client which wants to modify system call >>> arguments. >> >> But isn't the swizzling done in such way that all this is hidden from >> ptrace clients (and the rest of the kernel)? Why would a ptrace client >> need to know the details of the 32-bit entry call? >> >> The ptrace client can always modify the same registers, as system calls >> always use the same registers too. No unexpected behaviour happens as >> far as I can tell from looking at the code, at least not in the syscall >> entry path. > > The simple stuff works, but once you want to do things like change the > arguments and/or move the execution point, things get unswizzled in > uncontrolled ways. I do both and haven't encountered any problems. I can't find any unswizzling happening in the return path though. So from a ptracer's point of view it all looks the same after a system call, no matter how it was entered. Except for IP perhaps, but that's handled in the vDSO. > There are bug reports related to that (I would have > to dig them up) and they aren't really fixable in any sane way right now. I don't see any problems in the code. Only confusion I can think of is someone following the register values across a systemcall instruction. Then the swizzling may be unexpected. But if they do that they could check how the sycall was entered and compensate for that. (I can't think of any requirement why this would need to be race-free.) >> A pure 32-bit kernel is compiled with: >> >> #define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0))) > > ... which we'd like to get rid of ... If you do get rid of it, then you have to reload the registers after ptrace, just like currently happens on x86_64 kernels. So regparm(0) isn't a requirement, I only explained why reloading the registers isn't needed for pure 32-bit. Greetings, Indan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
