[Top] [All Lists]

Re: [PATCH v8 5/9] seccomp: split mode set routines

To: Oleg Nesterov <>
Subject: Re: [PATCH v8 5/9] seccomp: split mode set routines
From: Andy Lutomirski <>
Date: Wed, 25 Jun 2014 10:38:17 -0700
Cc: Kees Cook <>, LKML <>, "Michael Kerrisk (man-pages)" <>, Alexei Starovoitov <>, Andrew Morton <>, Daniel Borkmann <>, Will Drewry <>, Julien Tinnes <>, David Drysdale <>, Linux API <>, "" <>, "" <>,, linux-arch <>, linux-security-module <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <>
On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov <> wrote:
> On 06/25, Andy Lutomirski wrote:
>> Write the filter, then smp_mb (or maybe a weaker barrier is okay),
>> then set the bit.
> Yes, exactly, this is what I meant. Plas rmb() in __secure_computing().
> But I still can't understand the rest of your discussion about the
> ordering we need ;)

Let me try again from scratch.

Currently there are three relevant variables: TIF_SECCOMP,
seccomp.mode, and seccomp.filter.  __secure_computing needs
seccomp.mode and seccomp.filter to be in sync, and it wants (but
doesn't really need) TIF_SECCOMP to be in sync as well.

My suggestion is to rearrange it a bit.  Move mode into seccomp.filter
(so that filter == NULL implies no seccomp) and don't check
TIF_SECCOMP in secure_computing.  Then turning on seccomp is entirely
atomic except for the fact that the seccomp hooks won't be called if
filter != NULL but !TIF_SECCOMP.  This removes all ordering

Alternatively, __secure_computing could still BUG_ON(!seccomp.filter).
In that case, filter needs to be set before TIF_SECCOMP is set, but
that's straightforward.


<Prev in Thread] Current Thread [Next in Thread>