On Thu, January 26, 2012 11:31, Jamie Lokier wrote: > Indan Zupancic wrote: >> Yes, that's the only reason I'm interested in BPF, really. >> Most system calls are either always allowed, or always denied. >> Of the ones that need checking, most of them have file paths. >> For those I'm not interested in the post-syscall event. > > Same here, though for tracing file paths rather than blocking anything. The jailer I wrote works pretty well as a simplistic strace replacement. It can only print out the arguments we're checking, but that's usually the more interesting info. >> Those issues are not equivalent. ARM only has that OABI thing which >> is hopefully not used in practice. > > I am still using OABI on some currently-sold and still-developed > devices with userspace libraries that I can't replace or rebuild. > Maybe I'm the only one, but the issue is still there. It should be > supported in ptrace() as long as it's supported in the kernel at all. It's not a 32 versus 64-bit issue though, so it will be something on its own anyway. Can as well add an extra ARM specific ptrace command to get that info, or hack it in some other way. For instance, ip is (ab)used to tell if it is syscall entry or exit, so doing these tricks isn't anything new in ARM either. > I don't know if the PA-RISC thing is real. > > But it's occurred to me that there are a lot of 32/64 archs now (I was > extracting all their syscall number tables last night), and it would > be good if there were a consistent, arch-independent way to signal if > the syscall number is in the 32 or 64-bit table - or at least, in the > same ABI as the tracer gets from <asm/unistd.h>. For tracers doing > simple things to avoid needing a ton of arch-specific knowledge. You can't avoid the arch-specific knowledge, because depending on the answer, you have to do something arch specific. In ARM's OABI case, it's reading program memory to find out the system call number, of all things. (I hope I read the code wrong). So ARM's solution would need to get all info it needs to handle the system call securely without reading any text memory, otherwise it's racy. And then there's the whole confusion what that flag says, some might think it says in what mode the tracee is instead of what mode the system call is. That those two can be different is not obvious at all and seems very x86_64 specific. I'm not sure what you're doing, but perhaps we should share code and write a kind of Linux ptrace library. The code I wrote was university stuff and we want to release it, but it will take a while to get things sorted out. Hopefully it's released in April, maybe before. 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
