Oleg Nesterov wrote: > On 01/26, Denys Vlasenko wrote: > > > > On Wednesday 25 January 2012 20:36, Oleg Nesterov wrote: > > > > > > We can add the new events, > > > > > > PTRACE_EVENT_SYSCALL_ENTRY > > > PTRACE_EVENT_SYSCALL_COMPAT_ENTRY > > > PTRACE_EVENT_SYSCALL_EXIT > > > PTRACE_EVENT_SYSCALL_COMPAT_EXIT > > > > We can get away with just the first one. > > (1) It's unlikely people would want to get native sysentry events but not compat ones, > > thus first two options can be combined into one; > > Confused... Sure, we need the single option, or we could even report > this unconditionally if PT_SEIZED. > > I meant the different PTRACE_EVENT_* codes only. > > > (2) syscall exit compat-ness is known from entry type - no need to indicate it; and > > (3) if we would flag syscall entry with an event value in wait status, then syscall > > exit will be already distinquisable. > > Well, if we add _ENTRY then it looks more consistent to report _EXIT > as well even if it is not that useful. > > Doesn't matter. Nobody seem to like this, and afaics Linus has the > good arguments against the arch-independent "consolidation". Regarding distinction between ENTRY/EXIT: I agree only a buggy kernel should get out of sync, but are we sure the kernel is never buggy, and wouldn't this be nice protection, and an excuse for strace to drop the heuristics it currently does for this condition? The behaviour from fork() appears to have changed. (This is from reading kernel code, I'm too lazy to try out old kernels.) If I read correctly, before 2.5.35, Linux returned an EXIT event first to a child process if CLONE_PTRACE was used, and then it didn't, and then from 2.5.46 the tracer's use of PTRACE_EVENT_* determines if it does or not. So it's not surprising strace has heuristics... shame they're buggy (sigreturn can look like anything). Anyway, PTRACE_EVENT_* for syscall entry/exit just look prettier! Regarding ABI indication: At least with new syscalls, a tracer that doesn't know about them will see they're unrecognised; whereas a different ABI sometimes looks like an innocent syscall so can trick the tracer. However the argument for putting this in register state that goes into core dumps and checkpoint/restart state instead is pretty good. I don't have a strong opinion. It's unfortunate that the current method not only makes it easy to subvert a ptracer, it makes ptracing slow and racy on archs where it has to read the syscall instruction. (Weirdly that includes ARM, despite ARM using a register these days and having a ptrace option to set, but not read, the syscall number). That really is an argument for making sure all archs have the syscall number and, if necessary, the type of syscall entry point, somewhere in the register set. All the best, -- Jamie -- 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
