On Thu, February 9, 2012 05:29, H. Peter Anvin wrote: > On 02/08/2012 08:20 PM, Indan Zupancic wrote: >> >> 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? >> > > Uh... you could make THAT argument about ANY register state! Well, when the tracee is in a system call, it can't change registers, and their values determine the system call number and arguments. That information is stable for the current system call. And as a ptracer can't determine if the 32 or 64-bit syscall entry path was taken in a race-free way, it makes sense to provide that extra info. But the same is not true for the user space CPU mode, that can change at any time without the tracer getting a notification, except if it is single stepping (which I forgot about). Would it be useful to know the CPU mode when single stepping or otherwise? I'm asking because I don't see a need for it, but if someone else does it's better to add it now together with the syscall mode bit. Unlike the system call mode, the CPU mode can be checked via CS. The question is if that works well enough or if the values are dynamic enough that it's better to pass the info explicitly instead. Unlike the syscall mode info, figuring out the mode from CS isn't trivial when it can change dynamically. Then all places that use non-standard CS values need to be changed to provide the mode somehow. > I believe H.J. can fill you in about the usage. That would be great. >> >> 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.) >> > > You'd have to know how you'd entered, which right now you don't have any > way to know. You can check the syscall instruction itself, either before it's executed or afterwards by checking the IP. Though that's trickier, because the kernel points the IP to just after int80 for a sysenter call, so you have to check if there's a sysenter nearby too. You can also figure out what the entry instruction was by comparing the register values with the expected ones and deducing it that way. But the kernel is actually changing the registers, so why hide that? I mean, once user space is aware that the kernel may do swizzling, is there any actual problem left? Because this sounds like user space was trying to be clever, but got it wrong. E.g. it knew the kernel was entered not via int80, but then got confused because of the swizzling. 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
