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 1fEHex-0006Ox-UI for speck@linutronix.de; Thu, 03 May 2018 19:04:48 +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 w43H4eW4032341 for ; Thu, 3 May 2018 10:04:40 -0700 Date: Thu, 3 May 2018 10:04:39 -0700 From: Kees Cook Subject: [MODERATED] Re: [PATCH SSBv11 0/3] seccomp 1 Message-ID: <20180503170439.GD6017@outflux.net> References: <20180503122914.GV75137@tassilo.jf.intel.com> <20180503140932.t63gcxlaohfnavxk@gmail.com> MIME-Version: 1.0 In-Reply-To: <20180503140932.t63gcxlaohfnavxk@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, May 03, 2018 at 04:09:32PM +0200, speck for Ingo Molnar wrote: > * speck for Thomas Gleixner wrote: > > On Thu, 3 May 2018, speck for Andi Kleen wrote: > > > On Wed, May 02, 2018 at 05:44:27PM -0700, speck for Kees Cook wrote: > > > > From: Kees Cook > > > > Subject: opt-in under seccomp > > > > > > > > As seccomp use overlaps best (though not perfectly) with applications > > > > most likely to want speculation flaw mitigations enabled, seccomp will > > > > enable them when seccomp is enabled for a task. Also adds a line to > > > > /proc/$pid/status for examining the mitigation state of a task. > > > > > > As I wrote earlier this isn't a good idea. We went through > > > this earlier. > > > > > > It originally seems like a good idea until you start looking at the details. > > > > > > The big users of seccomp like the web browsers eventually > > > don't want it once they use site isolation. And it would > > > unnecessarily slow them down. > > > > > > And other programs need to be maintained anyways (e.g. for > > > spectre variant 1 fixes) so they can as well add it explicitely. > > > > > > Separate enabling makes more sense. And that is already in the patchkit. > > > > You're just ignoring the fact that they are not having it today and it's > > about providing the best out of the box protection right now. > > > > Telling people: "We have this shiny new prtcl and your browser will > > eventually use it but until then you're on your own." is just bullshit. > > > > Kees certainly knows what he is talking about and being involved in chrome > > gives him definitely more weight than your 'eventually don't want' and > > 'have to be maintained anyways' advisories which have exactly zero > > technical content. > > The other problem with 'site isolation' is that it doesn't necessarily solve or > even mitigate the problem: if for example malicious Javascript is injected from an > ad network, supposedly safely sandboxed, but it can still anomalously read site > local data via leaky speculation then that's still a dangerous violation of > sandboxing constraints: it could read pointers to defeat ASLR, it could read local > keys or other data it's not supposed to read. > > Once a browser specifically knows that it has fully mitigated against an attack it > can turn off any default mitigation early in its init sequence via the prctl, when > it still has full OS access and no seccomp isolation. All child tasks should > inherit that. 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. 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. -Kees -- Kees Cook @outflux.net