Re: [RFC PATCH for 4.18 1/2] rseq: validate rseq_cs fields are < TASK_SIZE

----- On Jun 29, 2018, at 11:54 AM, Linus Torvalds torvalds@linux-foundation.org wrote:

On Fri, Jun 29, 2018 at 8:27 AM Linus Torvalds
[off-list ref] wrote:

quoted

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