Re: [PATCH v7 3/9] seccomp: introduce writer locking

2014-06-24 Thread Kees Cook
On Tue, Jun 24, 2014 at 11:35 AM, Oleg Nesterov wrote: > On 06/24, Kees Cook wrote: >> On Tue, Jun 24, 2014 at 9:52 AM, Oleg Nesterov wrote: >> >> @@ -1142,6 +1168,7 @@ static struct task_struct *copy_process(unsigned >> >> long clone_flags, >> >> { >> >> int retval; >> >> struct ta

Re: [PATCH v7 3/9] seccomp: introduce writer locking

2014-06-24 Thread Kees Cook
On Tue, Jun 24, 2014 at 11:30 AM, Oleg Nesterov wrote: > I am puzzled by the usage of smp_load_acquire(), It was recommended by Andy Lutomirski in preference to ACCESS_ONCE(). > On 06/23, Kees Cook wrote: >> >> static u32 seccomp_run_filters(int syscall) >> { >> - struct seccomp_filter *f;

Re: [PATCH v7 3/9] seccomp: introduce writer locking

2014-06-24 Thread Oleg Nesterov
On 06/24, Kees Cook wrote: > > On Tue, Jun 24, 2014 at 9:52 AM, Oleg Nesterov 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 > (

Re: [PATCH v7 3/9] seccomp: introduce writer locking

2014-06-24 Thread Oleg Nesterov
I am puzzled by the usage of smp_load_acquire(), On 06/23, Kees Cook wrote: > > static u32 seccomp_run_filters(int syscall) > { > - struct seccomp_filter *f; > + struct seccomp_filter *f = smp_load_acquire(¤t->seccomp.filter); > struct seccomp_data sd; > u32 ret = SECCOMP_RET

Re: [PATCH v7 3/9] seccomp: introduce writer locking

2014-06-24 Thread Kees Cook
On Tue, Jun 24, 2014 at 9:52 AM, Oleg Nesterov 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

Re: [PATCH v7 3/9] seccomp: introduce writer locking

2014-06-24 Thread Oleg Nesterov
Kees, I am still trying to force myself to read and try to understand what this series does ;) Just a minor nit so far. 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

[PATCH v7 3/9] seccomp: introduce writer locking

2014-06-23 Thread Kees Cook
Normally, task_struct.seccomp.filter is only ever read or modified by the task that owns it (current). This property aids in fast access during system call filtering as read access is lockless. Updating the pointer from another task, however, opens up race conditions. To allow cross-thread filter