• Kees Cook's avatar
    seccomp: introduce writer locking · dbd95212
    Kees Cook authored
    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 pointer updates, writes to the
    seccomp fields are now protected by the sighand spinlock (which is shared
    by all threads in the thread group). Read access remains lockless because
    pointer updates themselves are atomic.  However, writes (or cloning)
    often entail additional checking (like maximum instruction counts)
    which require locking to perform safely.
    
    In the case of cloning threads, the child is invisible to the system
    until it enters the task list. To make sure a child can't be cloned from
    a thread and left in a prior state, seccomp duplication is additionally
    moved under the sighand lock. Then parent and child are certain have
    the same seccomp state when they exit the lock.
    
    Based on patches by Will Drewry and David Drysdale.
    Signed-off-by: default avatarKees Cook <keescook@chromium.org>
    Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
    Reviewed-by: default avatarAndy Lutomirski <luto@amacapital.net>
    dbd95212
seccomp.c 17.4 KB