From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga01.intel.com ([192.55.52.88]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fEDMP-0000Lj-1C for speck@linutronix.de; Thu, 03 May 2018 14:29:21 +0200 Date: Thu, 3 May 2018 05:29:14 -0700 From: Andi Kleen Subject: [MODERATED] Re: [PATCH SSBv11 0/3] seccomp 1 Message-ID: <20180503122914.GV75137@tassilo.jf.intel.com> References: 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 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. -Andi