----- On Jun 29, 2018, at 11:54 AM, Linus Torvalds [email protected] wrote:
> On Fri, Jun 29, 2018 at 8:27 AM Linus Torvalds > <[email protected]> wrote: >> >> You simply can't have it both ways. > > Put another way. > > This is ok in the native path: > > if ((unsigned long) rseq_cs->abort_ip != rseq_cs->abort_ip) > return -EINVAL; > > because it's checking that the value fits in the native register size > (and it also ends up being a no-op if the native size is the same size > as abort_ip). > > And this is very much ok in a compat syscall: > > if (rseq_cs->abort_ip & ~(unsigned long)-1u) > return -EINVAL; > > because it's checking that the pointer doesn't have (invalid in > compat) high bits set. > > But it is NOT OK to say "the rseq system call doesn't have any compat > syscall, but we'll do that compat check in the native case, because we > worry about compat issues". > > See what I'm saying? Either you worry about compat issues (and have a > compat syscall), or you don't. > > The whole "let's not do a compat syscall, but then check compat issues > at run-time in the native system call because compat processes will > use it" is braindamage. This code is not invoked from syscalls, but rather on return from interrupt/trap after a preemption. So a compat system call does not solve it. Unless we grab the "compat" state on rseq registration, save it in a rseq_compat flag within the task struct, and then use it on return from interrupt/trap/syscall. Otherwise we need to figure out whether we are dealing with a compat task when interrupt and trap context return to userspace. We had is_compat_task() for that before, but now it has vanished from x86. We could use user_64bit_mode(struct pt_regs *) on x86, but it does not exist on other architectures. One possibility is to introduce a new API that calls user_64bit_mode() on x86, and is_compat_task() on other archs. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
