From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wr0-x233.google.com ([2a00:1450:400c:c0c::233]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1fE7Ol-0001R7-Kh for speck@linutronix.de; Thu, 03 May 2018 08:07:23 +0200 Received: by mail-wr0-x233.google.com with SMTP id v15-v6so16214178wrm.10 for ; Wed, 02 May 2018 23:07:23 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id 194sm8227986wml.20.2018.05.02.23.07.17 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 02 May 2018 23:07:17 -0700 (PDT) Sender: Ingo Molnar Date: Thu, 3 May 2018 08:07:15 +0200 From: Ingo Molnar Subject: [MODERATED] Re: SBB V10 Bundle Message-ID: <20180503060715.pbit46ttgwjfbi4e@gmail.com> References: <20180502120716.ohnwlckp7qi7njs3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: To: speck@linutronix.de List-ID: * speck for Thomas Gleixner wrote: > > ==============> > > b4fe2032d782: prctl: Add speculation control prctls > > > > +/* Per task speculation control */ > > +#define PR_SET_SPECULATION_CTRL 52 > > +#define PR_GET_SPECULATION_CTRL 53 > > > > Please flip this around, i.e.: > > > > /* Per task speculation control */ > > #define PR_GET_SPECULATION_CTRL 52 > > #define PR_SET_SPECULATION_CTRL 53 > > > > because GET/SET is the canonical ABI order, used in most early prctl()s as well, > > until someone messed it up in PR_SET_TIMERSLACK, which bad example then everyone > > after that cargo-cult-copied ... Let's go back to the original ABI sanity. JFYI, you didn't reply to this one - forgot to reply? > > + case PR_SET_SPECULATION_CTRL: > > + if (arg4 || arg5) > > + return -EINVAL; > > > > So I think returning -ENOSYS might be better, to allow future extensions to use > > -EINVAL for a real invalid value - and allow -ENOSYS to be the "older kernel" > > disambiguation. For tools that care. > > Take that up with Linus. See his reply on that :) Sorry, if that was on this list then his remarks are either not in my archive, or Mutt doesn't properly search inside encrypted mails, or the list wasn't Cc:-ed to that reply. Mind quoting that reply here? Without having seen his reply: - When introducing _new_ ABIs then using -ENOSYS is entirely canonical for "no support exists that, yet". - For _existing_ driver and syscall interfaces using -ENOSYS can be indeed be confusing to apps and thus be the wrong thing to use. > > Also, a naive reading of the boot options: > > > > auto - Kernel detects whether the CPU model contains a > > implementation of Speculative Store Bypass and > > picks the most appropriate mitigation > > + prctl - Control Speculative Store Bypass for a thread > > + via prctl. By default it is enabled. The state > > + is inherited on fork. > > > > does not resolve the question of whether 'on', 'on', 'auto' or 'prctl' is the best > > option to use. I.e. the interaction of on/off/auto/prctl isn't clear IMHO. > > Can you come up with something better? Sure: auto - Kernel detects whether the CPU model contains a implementation of Speculative Store Bypass and picks the most appropriate mitigation global mitigation policy, which cannot be influenced by apps even via prctl. prctl - Control Speculative Store Bypass for a thread via prctl. By default mitigation is enabled. The state is inherited on fork. Btw., is it true that in the 'prctl' case mitigation is always enabled? If it's still CPU family/model sensitive like 'auto', which I think it is, then it might be more accurate to write: prctl - Control Speculative Store Bypass for a thread via prctl. By default mitigation is enabled on affected CPUs. The state is inherited on fork. or so? Thanks, Ingo