From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mta.outflux.net ([2001:19d0:2:6:c0de:0:736d:7471] helo=smtp.outflux.net) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fEGhX-0005Ly-Cc for speck@linutronix.de; Thu, 03 May 2018 18:03:25 +0200 Received: from www.outflux.net (serenity.outflux.net [10.2.0.2]) by vinyl.outflux.net (8.15.2/8.15.2/Debian-3) with ESMTP id w43G3Fwu024506 for ; Thu, 3 May 2018 09:03:15 -0700 Date: Thu, 3 May 2018 09:03:15 -0700 From: Kees Cook Subject: [MODERATED] Re: [PATCH SSBv11 3/3] seccomp 0 Message-ID: <20180503160315.GC6017@outflux.net> References: =?utf-8?q?=3C5f6464?= =?utf-8?q?d53346d3939a81cab15e5d5b20ad90c05d=2E1525308267=2Egit=2Ekeescoo?= =?utf-8?q?k=40chromium=2Eorg=3E?= <20180503085800.GX12217@hirez.programming.kicks-ass.net> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, May 03, 2018 at 11:21:36AM +0200, speck for Thomas Gleixner wrote: > On Thu, 3 May 2018, speck for Peter Zijlstra wrote: > > On Tue, May 01, 2018 at 03:07:31PM -0700, speck for Kees Cook wrote: > > > @@ -239,6 +254,9 @@ static inline void seccomp_assign_mode(struct task_struct *task, > > > */ > > > smp_mb__before_atomic(); > > > set_tsk_thread_flag(task, TIF_SECCOMP); > > > + > > > + /* Assume seccomp processes want speculation flaw mitigation. */ > > > + spec_mitigate(task, PR_SPEC_STORE_BYPASS); > > > } > > > > What about the ordering there? That function appears to explicitly set > > TIF_SECCOMP last, such that when that is observed, the complete > > environment is observed. > > > > But now you add something after it. Does this not mean that if you set > > this on a remote task, this task can execute TIF_SECCOMP thing before it > > disables SSB. > > > > Is that OK? > > It probably should be the other way round. I can swap it around. For the seccomp case, it's a thread in the current thread group, so it's not TOTALLY remote. :) In the case of thread-sync for seccomp, it is expected to be "correct at next scheduling". -Kees -- Kees Cook @outflux.net