From: Andy Lutomirski <luto@kernel.org>
To: Tycho Andersen <tycho@tycho.ws>
Cc: Andy Lutomirski <luto@kernel.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Christian Brauner <christian.brauner@canonical.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux Containers <containers@lists.linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
Oleg Nesterov <oleg@redhat.com>,
"Eric W . Biederman" <ebiederm@xmission.com>,
Christian Brauner <christian.brauner@ubuntu.com>,
Tyler Hicks <tyhicks@canonical.com>,
Akihiro Suda <suda.akihiro@lab.ntt.co.jp>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>
Subject: Re: [RFC 0/3] seccomp trap to userspace
Date: Fri, 16 Mar 2018 00:46:55 +0000 [thread overview]
Message-ID: <CALCETrWH7HbY2gS6O_cYKfp9QqqWBWVcHb++GaP3uUiSO9oo6g@mail.gmail.com> (raw)
In-Reply-To: <20180315173524.k7vwnvnhomg2j5yv@smitten>
On Thu, Mar 15, 2018 at 5:35 PM, Tycho Andersen <tycho@tycho.ws> wrote:
> Hi Andy,
>
> On Thu, Mar 15, 2018 at 05:11:32PM +0000, Andy Lutomirski wrote:
>> On Thu, Mar 15, 2018 at 5:05 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
>> > Hm, synchronously - that brings to mind a thought... I should re-look at
>> > Tycho's patches first, but, if I'm in a container, start some syscall that
>> > gets trapped to userspace, then I hit ctrl-c. I'd like to be able to have
>> > the handler be interrupted and have it return -EINTR. Is that going to
>> > be possible with the synchronous approach?
>>
>> I think so, but it should be possible with the classic async approach
>> too. The main issue is the difference between a classic filter like
>> this (pseudocode):
>>
>> if (nr == SYS_mount) return TRAP_TO_USERSPACE;
>>
>> and the eBPF variant:
>>
>> if (nr == SYS_mount) trap_to_userspace();
>
> Sargun started a private design discussion thread that I don't think
> you were on, but Alexei said something to the effect of "eBPF programs
> will never wait on userspace", so I'm not sure we can do something
> like this in an eBPF program. I'm cc-ing him here again to confirm,
> but I doubt things have changed.
>
>> I admit that it's still not 100% clear to me that the latter is
>> genuinely more useful than the former.
>>
>> The case where I think the synchronous function call is a huge win is this one:
>>
>> if (nr == SYS_mount) {
>> log("Someone called mount with args %lx\n", ...);
>> return RET_KILL;
>> }
>>
>> The idea being that the log message wouldn't show up in the kernel log
>> -- it would get sent to the listener socket belonging to whoever
>> created the filter, and that process could then go and log it
>> properly. This would work perfectly in containers and in totally
>> unprivileged applications like Chromium.
>
> The current implementation can't do exactly this, but you could do:
>
> if (nr == SYS_mount) {
> log(...);
> kill(pid, SIGKILL);
> }
>
> from the handler instead.
>
> I guess Serge is asking a slightly different question: what if the
> task gets e.g. SIGINT from the user doing a ^C or SIGALARM or
> something, we should probably send the handler some sort of message or
> interrupt to let it know that the syscall was cancelled. Right now the
> current set doesn't behave that way, and the handler will just
> continue on its merry way and get an EINVAL when it tries to respond
> with the cancelled cookie.
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:
send_to_listener("hey I got a signal");
wait_ret = wait_interruptible for the listener to reply;
if (wait_ret == -EINTR) {
send_to_listener("hey there's a signal");
wait_ret = wait_killable for the listener to reply to the original request;
}
if (wait_ret == -EINTR) {
/* hmm, this next line might not actually be necessary, but it's
harmless and possibly useful */
send_to_listener("hey we're going away");
/* and stop waiting */
}
... actually handle the result.
--Andy
next prev parent reply other threads:[~2018-03-16 0:47 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-04 10:49 [RFC 0/3] seccomp trap to userspace Tycho Andersen
2018-02-04 10:49 ` [RFC 1/3] seccomp: add a return code to " Tycho Andersen
2018-02-04 17:36 ` Andy Lutomirski
2018-02-04 20:01 ` Tycho Andersen
2018-02-04 20:33 ` Andy Lutomirski
2018-02-05 8:47 ` Tycho Andersen
2018-02-13 21:09 ` Kees Cook
2018-02-14 15:29 ` Tycho Andersen
2018-02-14 17:19 ` Andy Lutomirski
2018-02-14 17:23 ` Tycho Andersen
2018-02-15 14:48 ` Christian Brauner
2018-02-27 0:49 ` Kees Cook
2018-02-27 3:27 ` Andy Lutomirski
2018-02-04 10:49 ` [RFC 2/3] seccomp: hoist out filter resolving logic Tycho Andersen
2018-02-13 21:29 ` Kees Cook
2018-02-14 15:33 ` Tycho Andersen
2018-02-04 10:49 ` [RFC 3/3] seccomp: add a way to get a listener fd from ptrace Tycho Andersen
2018-02-13 21:32 ` Kees Cook
2018-02-14 15:33 ` Tycho Andersen
2018-03-15 16:09 ` [RFC 0/3] seccomp trap to userspace Christian Brauner
2018-03-15 16:56 ` Andy Lutomirski
2018-03-15 17:05 ` Serge E. Hallyn
2018-03-15 17:11 ` Andy Lutomirski
2018-03-15 17:25 ` Christian Brauner
2018-03-15 17:30 ` Andy Lutomirski
2018-03-15 17:35 ` Tycho Andersen
2018-03-16 0:46 ` Andy Lutomirski [this message]
2018-03-16 14:47 ` Christian Brauner
2018-03-16 16:01 ` Andy Lutomirski
2018-03-16 16:40 ` Christian Brauner
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=CALCETrWH7HbY2gS6O_cYKfp9QqqWBWVcHb++GaP3uUiSO9oo6g@mail.gmail.com \
--to=luto@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=christian.brauner@canonical.com \
--cc=christian.brauner@ubuntu.com \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=serge@hallyn.com \
--cc=suda.akihiro@lab.ntt.co.jp \
--cc=tycho@tycho.ws \
--cc=tyhicks@canonical.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).