From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga05.intel.com ([192.55.52.43]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fEJQn-0007uj-Dv for speck@linutronix.de; Thu, 03 May 2018 20:58:17 +0200 Date: Thu, 3 May 2018 11:58:14 -0700 From: Andi Kleen Subject: [MODERATED] Re: [PATCH SSBv11 0/3] seccomp 1 Message-ID: <20180503185814.GY75137@tassilo.jf.intel.com> References: <20180503122914.GV75137@tassilo.jf.intel.com> <20180503140932.t63gcxlaohfnavxk@gmail.com> <20180503170439.GD6017@outflux.net> MIME-Version: 1.0 In-Reply-To: <20180503170439.GD6017@outflux.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: > 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? > > 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. -Andi