From: Kees Cook <keescook@chromium.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Alexei Starovoitov <ast@plumgrid.com>,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Daniel Borkmann <dborkman@redhat.com>,
Will Drewry <wad@chromium.org>, Julien Tinnes <jln@chromium.org>,
David Drysdale <drysdale@google.com>,
Linux API <linux-api@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-mips@linux-mips.org,
linux-arch <linux-arch@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH v7 3/9] seccomp: introduce writer locking
Date: Tue, 24 Jun 2014 11:02:04 -0700 [thread overview]
Message-ID: <CAGXu5j+G8qAkGD7H=3R2iw2ZTqZSrMPa2f=czoEjwSW5wKqUWQ@mail.gmail.com> (raw)
In-Reply-To: <20140624165216.GA29272@redhat.com>
On Tue, Jun 24, 2014 at 9:52 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> Kees,
>
> I am still trying to force myself to read and try to understand what
> this series does ;) Just a minor nit so far.
The use-case this solves is when a userspace process does not control
(or know) when a thread is spawned (e.g. via shared library init, or
LD_PRELOAD) but wants to make sure seccomp filters have been applied
to it. Specifically, Chrome, when loading some proprietary graphics
drivers, will have those drivers spawning threads before there has
been an ability to call seccomp. While some games can be played to get
ahead of it, it's not always possible, or racey, depending on the
drivers. With seccomp thread-sync, we can be certain that all threads
have had the filter applied.
>
> On 06/23, Kees Cook wrote:
>>
>> @@ -1142,6 +1168,7 @@ static struct task_struct *copy_process(unsigned long clone_flags,
>> {
>> int retval;
>> struct task_struct *p;
>> + unsigned long irqflags;
>>
>> if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))
>> return ERR_PTR(-EINVAL);
>> @@ -1196,7 +1223,6 @@ static struct task_struct *copy_process(unsigned long clone_flags,
>> goto fork_out;
>>
>> ftrace_graph_init_task(p);
>> - get_seccomp_filter(p);
>>
>> rt_mutex_init_task(p);
>>
>> @@ -1434,7 +1460,13 @@ static struct task_struct *copy_process(unsigned long clone_flags,
>> p->parent_exec_id = current->self_exec_id;
>> }
>>
>> - spin_lock(¤t->sighand->siglock);
>> + spin_lock_irqsave(¤t->sighand->siglock, irqflags);
>> +
>> + /*
>> + * Copy seccomp details explicitly here, in case they were changed
>> + * before holding tasklist_lock.
>> + */
>> + copy_seccomp(p);
>>
>> /*
>> * Process group and session signals need to be delivered to just the
>> @@ -1446,7 +1478,7 @@ static struct task_struct *copy_process(unsigned long clone_flags,
>> */
>> recalc_sigpending();
>> if (signal_pending(current)) {
>> - spin_unlock(¤t->sighand->siglock);
>> + spin_unlock_irqrestore(¤t->sighand->siglock, irqflags);
>> write_unlock_irq(&tasklist_lock);
>> retval = -ERESTARTNOINTR;
>> goto bad_fork_free_pid;
>> @@ -1486,7 +1518,7 @@ static struct task_struct *copy_process(unsigned long clone_flags,
>> }
>>
>> total_forks++;
>> - spin_unlock(¤t->sighand->siglock);
>> + spin_unlock_irqrestore(¤t->sighand->siglock, irqflags);
>> write_unlock_irq(&tasklist_lock);
>> proc_fork_connector(p);
>> cgroup_post_fork(p);
>
> It seems that the only change copy_process() needs is copy_seccomp() under the locks.
> Everythinh else (irqflags games) looks obviously unneeded?
I got irq lock dep warnings without these changes. If they're
unneeded, that's totally fine by me, but some change (either this or
markings to keep lockdep happy) is needed.
>> @@ -524,6 +528,9 @@ static long seccomp_set_mode(unsigned long seccomp_mode, char __user *filter)
>> }
>> #endif
>>
>> + if (unlikely(!lock_task_sighand(current, &irqflags)))
>> + goto out_free;
>> +
>
> Unless this task is exiting (namely, it has already called exit_notify()),
> lock_task_sighand(current) must not fail. Looks like you can simply do
> spin_lock_irq(->siglock).
Okay. I wasn't sure if I needed to be extra careful here or not. I
opted for just using lock_task_sighand since that seemed to be the
most used. :)
-Kees
--
Kees Cook
Chrome OS Security
next prev parent reply other threads:[~2014-06-24 18:02 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-23 21:58 [PATCH v7 0/9] seccomp: add thread sync ability Kees Cook
2014-06-23 21:58 ` [PATCH v7 1/9] seccomp: create internal mode-setting function Kees Cook
2014-06-23 21:58 ` [PATCH v7 2/9] seccomp: split filter prep from check and apply Kees Cook
2014-06-26 12:37 ` David Drysdale
2014-06-27 18:45 ` Kees Cook
2014-06-23 21:58 ` [PATCH v7 3/9] seccomp: introduce writer locking Kees Cook
2014-06-24 16:52 ` Oleg Nesterov
2014-06-24 18:02 ` Kees Cook [this message]
2014-06-24 18:35 ` Oleg Nesterov
2014-06-24 20:26 ` Kees Cook
2014-06-24 18:30 ` Oleg Nesterov
2014-06-24 19:46 ` Kees Cook
2014-06-23 21:58 ` [PATCH v7 4/9] seccomp: move no_new_privs into seccomp Kees Cook
2014-06-24 19:18 ` Oleg Nesterov
2014-06-24 19:20 ` Andy Lutomirski
2014-06-24 19:30 ` Oleg Nesterov
2014-06-24 19:34 ` Andy Lutomirski
2014-06-24 19:50 ` Kees Cook
2014-06-24 19:51 ` Andy Lutomirski
2014-06-23 21:58 ` [PATCH v7 5/9] seccomp: split mode set routines Kees Cook
2014-06-23 21:58 ` [PATCH v7 6/9] seccomp: add "seccomp" syscall Kees Cook
2014-06-23 21:58 ` [PATCH v7 7/9] seccomp: implement SECCOMP_FILTER_FLAG_TSYNC Kees Cook
2014-06-24 17:08 ` Oleg Nesterov
2014-06-24 18:19 ` Kees Cook
2014-06-24 17:27 ` Oleg Nesterov
2014-06-24 18:05 ` Kees Cook
2014-06-24 18:37 ` Oleg Nesterov
2014-06-24 19:08 ` Kees Cook
2014-06-23 21:58 ` [PATCH v7 8/9] ARM: add seccomp syscall Kees Cook
2014-06-23 21:58 ` [PATCH v7 9/9] MIPS: " Kees Cook
2014-06-23 22:01 ` [PATCH v7 1/1] man-pages: seccomp.2: document syscall Kees Cook
2014-06-24 10:23 ` Michael Kerrisk (man-pages)
2014-06-24 16:43 ` Kees Cook
2014-06-24 17:48 ` [PATCH v7.1 " Kees Cook
2014-06-24 18:06 ` [PATCH v7 " Andy Lutomirski
2014-06-24 19:18 ` Kees Cook
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='CAGXu5j+G8qAkGD7H=3R2iw2ZTqZSrMPa2f=czoEjwSW5wKqUWQ@mail.gmail.com' \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=ast@plumgrid.com \
--cc=dborkman@redhat.com \
--cc=drysdale@google.com \
--cc=jln@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mtk.manpages@gmail.com \
--cc=oleg@redhat.com \
--cc=wad@chromium.org \
--cc=x86@kernel.org \
/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).