On Tue, Jan 19, 2016 at 3:11 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Tue, Jan 19, 2016 at 2:18 PM, David Miller <davem@xxxxxxxxxxxxx> wrote: >> From: Andy Lutomirski <luto@xxxxxxxxxxxxxx> >> Date: Tue, 19 Jan 2016 14:14:43 -0800 >> >>> On Tue, Jan 19, 2016 at 1:55 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: >>>> On Tue, Jan 19, 2016 at 01:47:24PM -0800, Andy Lutomirski wrote: >>>>> Essentially all users of is_compat_task in the kernel are trying to >>>>> determine whether they are executing in the context of a compat >>>>> syscall. On at least x86_64 and sparc, these are not at all the >>>>> same question. >>>>> >>>>> On x86_64 and sparc, therefore, is_compat_task doesn't return the >>>>> overall compat state of the task; it returns true if the task is >>>>> currently in a compat syscall. >>>> >>>> The hell it does. Andy, TIF_32BIT is *NOT* set on syscall entry; it is >>>> set by execve(). And 64bit task (with that bit clear) can bloody well >>>> issue 32bit syscalls. Really. >>> >>> It does on x86. It does not on sparc. But syscall_get_arch on sparc >>> *also* doesn't appear to work right. >>> >>> davem, how can I check the current syscall bitness on sparc? It's not >>> obvious to me that it's possible. >> >> You have to do it by context if it's important. >> > > What does "by context" mean? This is definitely important for seccomp > and audit, and I think it's probably important for other users, too. > >> In addition to the example Al gave, 32-bit processes can make 64-bit >> syscalls too. GDB and other ptrace() using applications can use this >> to trace 64-bit programs from 32-bit tracer apps. > > On x86, is_compat_task returns true in 32-bit syscalls and false in > 64-bit syscalls. So a 64-bit task that calls a 32-bit syscall gets > is_compat_task. > > I think that the naming makes no sense whatsoever but that the > behavior is actually desirable. If I'm a 32-bit task and I call > 64-bit ptrace() [1], I think I want to see the 64-bit siginfo format, > not the 32-bit format. A bunch of the drivers that use is_compat_task > are specifically trying to distinguish compat from non-compat ioctls. > The SPARC is_compat_task implementation doesn't do that. > > I'm trying to phase out is_compat_task entirely from non-arch code. > The WIP version is here: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=in_compat_syscall > > but it has issues on SPARC. Can we use pt_regs_trap_type for this? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
