From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1fEEvV-0002VW-IZ for speck@linutronix.de; Thu, 03 May 2018 16:09:41 +0200 Received: by mail-wm0-x230.google.com with SMTP id f8so20162718wmc.4 for ; Thu, 03 May 2018 07:09:41 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id k3-v6sm24374172wri.28.2018.05.03.07.09.34 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 03 May 2018 07:09:34 -0700 (PDT) Sender: Ingo Molnar Date: Thu, 3 May 2018 16:09:32 +0200 From: Ingo Molnar Subject: [MODERATED] Re: [PATCH SSBv11 0/3] seccomp 1 Message-ID: <20180503140932.t63gcxlaohfnavxk@gmail.com> References: <20180503122914.GV75137@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: * 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. Thanks, Ingo