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 1fENTi-0006kC-Ln for speck@linutronix.de; Fri, 04 May 2018 01:17:36 +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 w43NHRHt016178 for ; Thu, 3 May 2018 16:17:27 -0700 Date: Thu, 3 May 2018 16:17:26 -0700 From: Kees Cook Subject: [MODERATED] Re: [PATCH SSBv11 0/3] seccomp 1 Message-ID: <20180503231726.GE6017@outflux.net> References: <20180503122914.GV75137@tassilo.jf.intel.com> <20180503140932.t63gcxlaohfnavxk@gmail.com> <20180503170439.GD6017@outflux.net> <20180503185814.GY75137@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: <20180503185814.GY75137@tassilo.jf.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, May 03, 2018 at 11:58:14AM -0700, speck for Andi Kleen wrote: > > My goal is providing SOME kind of "by default" coverage that doesn't > > require an admin to write new code or wait for a software vendor to provide > > an update. > > What's your target for this? Is it the web browser or something else? My target is "something unexpected" as we can't know what all the containers in the world are actually containing. (And, while SpectreV1 is still an issue, it'd be nice to have coverage against SSB for browsers that are slow with Site Isolation.) > > If it is tolerable to wait for a vendor to _enable_ the mitigation, then > > it should be tolerable to wait for a vendor to _disable_ the mitigation > > as well. i.e. we protect a targeted subset of processes (those using > > seccomp) but provide a way to disable it later. To that end, how about > > a new prctl or seccomp flag that indicates "do no enable speculation > > mitigations under seccomp"? That would give any seccomp users the ability > > to opt-out if they wanted to. > > Yes if you add it to seccomp that would be needed. > > It should already work with the existing prctl? Need to test that. > > The problem with the prctl of course is that it would override external > user choice. But perhaps that is ok. I think tglx and I cooked up a workable solution. seccomp users will now be able to individually opt out of the automatic mitigation (by adding the new SECCOMP_FILTER_FLAG_SPEC_ALLOW flag), and sysadmins will be able to globally opt out of the seccomp behavior by booting with "spec_store_bypass_disable=prctl". (The default is "seccomp" which is prctl plus seccomp.) If it turns out immediately that seccomp coverage was a terrible idea, we can switch the default back to "prctl". And maybe in a few years once we're happy with the state of software vulnerable to SSB, we can do the same. -Kees -- Kees Cook @outflux.net