linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Gabriel Krisman Bertazi <krisman@collabora.com>
Cc: Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel@collabora.com, Matthew Wilcox <willy@infradead.org>,
	Paul Gofman <gofmanp@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>, Shuah Khan <shuah@kernel.org>
Subject: Re: [PATCH v4 1/2] kernel: Implement selective syscall userspace redirection
Date: Thu, 16 Jul 2020 21:48:50 -0700	[thread overview]
Message-ID: <CALCETrUOe=a35rb-o44vLOSHmQ45EuommwoL2quowzw3h+J2gg@mail.gmail.com> (raw)
In-Reply-To: <87wo32j394.fsf@collabora.com>

On Thu, Jul 16, 2020 at 7:15 PM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Andy Lutomirski <luto@kernel.org> writes:
>
> > On Thu, Jul 16, 2020 at 12:31 PM Gabriel Krisman Bertazi
> > <krisman@collabora.com> wrote:
> >>
> >
> > This is quite nice.  I have a few comments, though:
> >
> > You mentioned rt_sigreturn().  Should this automatically exempt the
> > kernel-provided signal restorer on architectures (e.g. x86_32) that
> > provide one?
>
> That seems reasonable.  Not sure how easy it is to do it, though.

For better or for worse, it's currently straightforward because the code is:

__kernel_sigreturn:
.LSTART_sigreturn:
        popl %eax               /* XXX does this mean it needs unwind info? */
        movl $__NR_sigreturn, %eax
        SYSCALL_ENTER_KERNEL

and SYSCALL_ENTER_KERNEL is hardwired as int $0x80.  (The latter is
probably my fault, for better or for worse.)  So this would change to:

__vdso32_sigreturn_syscall:
  SYSCALL_ENTER_KERNEL

and vdso2c would wire up __vdso32_sigreturn_syscall.  Then there would
be something like:

bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs);

and that would be that.  Does anyone have an opinion as to whether
this is a good idea?  Modern glibc shouldn't be using this mechanism,
I think, but I won't swear to it.

>
> > The amount of syscall entry wiring that arches need to do is IMO
> > already a bit out of hand.  Should we instead rename TIF_SECCOMP to
> > TIF_SYSCALL_INTERCEPTION and have one generic callback that handles
> > seccomp and this new thing?
>
> Considering the previous suggestion from Kees to hide it inside the
> tracehook and Thomas rework of this path, I'm not sure what is the best
> solution here, but some rework of these flags is due.  Thomas suggested
> expanding these flags to 64 bits and having some arch specific and
> arch-agnostic flags.  With the storage expansion and arch-agnostic flags,
> would this still be desirable?

I think it would be desirable to consolidate this to avoid having
multiple arches need to separately wire up all of these mechanisms.
I'm not sure that the initial upstream implementation needs this, but
it might be nice to support this out of the box on all arches with
seccomp support.

>
> >> +int do_syscall_user_dispatch(struct pt_regs *regs)
> >> +{
> >> +       struct syscall_user_dispatch *sd = &current->syscall_dispatch;
> >> +       unsigned long ip = instruction_pointer(regs);
> >> +       char state;
> >> +
> >> +       if (likely(ip >= sd->dispatcher_start && ip <= sd->dispatcher_end))
> >> +               return 0;
> >> +
> >> +       if (likely(sd->selector)) {
> >> +               if (unlikely(__get_user(state, sd->selector)))
> >> +                       do_exit(SIGSEGV);
> >> +
> >> +               if (likely(state == 0))
> >> +                       return 0;
> >> +
> >> +               if (state != 1)
> >> +                       do_exit(SIGSEGV);
> >
> > This seems a bit extreme and hard to debug if it ever happens.
>
> Makes sense, but I don't see a better way to return the error here.
> Maybe a SIGSYS with a different si_errno?  Alternatively, we could
> revert to the previous behavior of allowing syscalls on state != 0, that
> existed in v1.  What do you think?
>

I don't have a strong opinion.  SIGSYS with different si_errno is
probably reasonable.

--Andy

  reply	other threads:[~2020-07-17  4:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-16 19:31 [PATCH v4 0/2] Syscall User Redirection Gabriel Krisman Bertazi
2020-07-16 19:31 ` [PATCH v4 1/2] kernel: Implement selective syscall userspace redirection Gabriel Krisman Bertazi
2020-07-16 21:06   ` Matthew Wilcox
2020-07-16 21:26     ` Kees Cook
2020-07-17  0:20   ` Andy Lutomirski
2020-07-17  2:15     ` Gabriel Krisman Bertazi
2020-07-17  4:48       ` Andy Lutomirski [this message]
2020-07-21 12:06         ` Mark Rutland
2020-07-20  9:23     ` Thomas Gleixner
2020-07-20  9:44       ` Will Deacon
2020-07-20 10:08   ` Thomas Gleixner
2020-07-20 13:46     ` Gabriel Krisman Bertazi
2020-07-16 19:31 ` [PATCH v4 2/2] selftests: Add kselftest for syscall user dispatch Gabriel Krisman Bertazi
2020-07-16 20:04 ` [PATCH v4 0/2] Syscall User Redirection Kees Cook
2020-07-16 20:22   ` Christian Brauner
2020-07-16 20:25     ` Kees Cook
2020-07-16 20:29       ` Christian Brauner
2020-07-16 20:30         ` Gabriel Krisman Bertazi
2020-07-16 21:06           ` Carlos O'Donell
2020-08-02 12:01 ` Pavel Machek
2020-08-04 14:26   ` Gabriel Krisman Bertazi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALCETrUOe=a35rb-o44vLOSHmQ45EuommwoL2quowzw3h+J2gg@mail.gmail.com' \
    --to=luto@kernel.org \
    --cc=gofmanp@gmail.com \
    --cc=keescook@chromium.org \
    --cc=kernel@collabora.com \
    --cc=krisman@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=willy@infradead.org \
    --subject='Re: [PATCH v4 1/2] kernel: Implement selective syscall userspace redirection' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).