Andi Kleen wrote: >On Tuesday 08 November 2005 05:39, Zachary Amsden wrote: > > >>IA-32 linear address translation is loads of fun. >> >> > >Thanks for doing that audit work. Can you please double check x86-64 code is >ok? > >Actually giving all that complexity maybe it would be better to just >stop handling the case and remove all that. I'm not sure what kprobes needs it >for - it doesn't even handle user space yet and even if it ever does it is >unlikely that handling 16bit code makes much sense. And the prefetch >workaround does it, but 16bit DOS code is unlikely to contain prefetches >anyways. And for ptrace - well, who cares? I suppose dosemu has an own >debugger anyways and it could be handled in user space (i suppose >they still have that code from 2.4 anyways) > > I got the idea from the x86-64 code; prompted by you, I looked at it, and it appears correct, but I would like to give it a full audit as well (especially regarding 32-bit compatibility segments). About the three cases here: The prefetch workaround should be harmless, again because of limit checking, the kernel is safe even in the raceful cases. One can imagine clever uses for ptrace to do, say user space virtualization (since I'm on the topic), or other neat things. So there is nothing really wrong about having the fully correct EIP conversion (and here we shouldn't need to worry about races causing some issues with strict correctness, since there can be one external control thread). But were kprobes even inteneded for userspace? There are races here that are difficult to close without some heavy machinery, and I would rather not put the machinery in place if simplifying the code is the right answer. Zach
