Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC 0/3] seccomp trap to userspace
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <20180316144751.GA3304@mailbox.org>
Date:   Fri, 16 Mar 2018 09:01:47 -0700
Cc:     Andy Lutomirski <luto@kernel.org>, Tycho Andersen <tycho@tycho.ws>,
        Kees Cook <keescook@chromium.org>,
        Linux Containers <containers@lists.linux-foundation.org>,
        Akihiro Suda <suda.akihiro@lab.ntt.co.jp>,
        LKML <linux-kernel@vger.kernel.org>,
        Oleg Nesterov <oleg@redhat.com>,
        Christian Brauner <christian.brauner@canonical.com>,
        "Eric W . Biederman" <ebiederm@xmission.com>,
        Christian Brauner <christian.brauner@ubuntu.com>,
        Tyler Hicks <tyhicks@canonical.com>,
        Alexei Starovoitov <alexei.starovoitov@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D73E5C37-DC92-4D58-A163-0B20143AAEEB@amacapital.net>
References: <20180204104946.25559-1-tycho@tycho.ws> <20180315160924.GA12744@gmail.com> <CALCETrVnvbZLx5v=DMu2N1JtR+ys507X5CYBi-qQnus3VMQdwg@mail.gmail.com> <20180315170509.GA32766@mail.hallyn.com> <CALCETrXPcCNbpFJhXktkVS9gOPpmnU_bbY6Z8RrsBarq0dP4Lg@mail.gmail.com> <20180315173524.k7vwnvnhomg2j5yv@smitten> <CALCETrWH7HbY2gS6O_cYKfp9QqqWBWVcHb++GaP3uUiSO9oo6g@mail.gmail.com> <20180316144751.GA3304@mailbox.org>
To:     Christian Brauner <christian.brauner@mailbox.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Mar 16, 2018, at 7:47 AM, Christian Brauner <christian.brauner@mailbox.=
org> wrote:
>=20
>> On Fri, Mar 16, 2018 at 12:46:55AM +0000, Andy Lutomirski wrote:


I bet I confused everyone with a blatant typo:

>>=20
>> Hmm, I think we have to be very careful to avoid nasty races.  I think
>> the correct approach is to notice the signal and send a message to the
>> listener that a signal is pending but to take no additional action.
>> If the handler ends up completing the syscall with a successful
>> return, we don't want to replace it with -EINTR.  IOW the code looks
>> kind of like:
>>=20
>> send_to_listener("hey I got a signal");

That should be =E2=80=9Chey I got a syscall=E2=80=9D.   D=E2=80=99oh!

>> wait_ret =3D wait_interruptible for the listener to reply;
>> if (wait_ret =3D=3D -EINTR) {
>=20
> Hm, so from the pseudo-code it looks like: The handler would inform the
> listener that it received a signal (either from the syscall requester or
> from somewhere else) and then wait for the listener to reply to that
> message.  This would allow the listener to decide what action it wants
> the handler to take based on the signal, i.e. either cancel the request
> or retry?  The comment makes it sound like that the handler doesn't
> really wait on the listener when it receives a signal it simply moves
> on.

It keeps waiting killably but not interruptibly.=20

> So no "taking no additional action" here means not have the handler
> decide to abort but the listener?

If by =E2=80=9Chandler=E2=80=9D you mean kernel, then yes.=20

There=E2=80=99s no userspace syscall handler involved. =46rom the kernel=E2=80=
=99s perspective, a syscall is never still in progress when a signal handler=
 is invoked =E2=80=94 we only actually invoke syscall handlers in prepare_ex=
it_to_usermode() or the non-x86 equivalent and the functions it calls. While=
 a syscall is running, the kernel might notice that a signal is pending and d=
o one of a few things:

1. Just keep going. Not all syscalls can be interrupted.=20

2. Try to finish early. If a send() call has already sent some but not all d=
ata, it can stop waiting and return the number of bytes sent.

3. Abort with -EINTR.

4. Abort with -ERESTARTSYS or one of its relatives. These fiddle with user r=
egisters in a somewhat unpleasant way to pretend that the syscall never actu=
ally happened.  This works for syscalls that wait with an absolute timeout, f=
or example.=20

5. Set up restart_syscall() magic, rewrite regs so it looks like the user wa=
s about to call restart_syscall() when the signal happened, and abort.=20

In all cases, the signal is dealt with afterwards. This could result in chan=
ging regs to call the handler or in simply returning.=20

1-3 should work fully in seccomp. The only issue is that the kernel doesn=E2=
=80=99t know *which* to do, nor can the kernel force the listener to abort c=
leanly, so I think we have  no real choice but to let the listener decide.=20=


4 could be supported just like 1-3. 5 is awful, and I don=E2=80=99t think we=
 should support it for user listeners.=20