[MODERATED] Re: SBB V10 Bundle

[Ingo Molnar <mingo@kernel.org>]

* speck for Thomas Gleixner <speck@linutronix.de> 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