On 04/27/2018 01:37 PM, speck for Thomas Gleixner wrote:
> On Fri, 27 Apr 2018, speck for Jon Masters wrote:
>> Konrad and I are sitting here chatting in my office. We debated the
>> enumeration for this. Do we think simply calling and getting an EINVAL
>> on older kernels is ok, or do we need a specific enumeration for the
>> ability to control SSB from software? An enumeration would be nice. You
>> might want to look to how the kernel handles MPX today to indicate
>> whether the prctl implemented, and also whether runtime supported.
> 
> So if you looked at what I wrote earlier:
> 
> int arch_prctl_set_rds(struct task_struct *p, unsigned long val)
> {
>         if (!spec_store_bypass_prctl)
>                 return -ENOTSUPP;
> 

The ENOTSUPP is in include/linux/errno.h and
not in userspace api, can we return that?

There is a comment in the include/linux/errno.h that says:
/*
 * These should never be seen by user programs....

and then 
/* Defined for the NFSv3 protocol */


> That's exactly the point. If the (older or not updated) kernel does not
> support it then you get -EINVAL because thats the default for not
> implemented prctls.
> 
> So if spec_store_bypass_prctl is not enabled you can return some other
> error code and we surely can make that error code depend on the mitigation
> state and return -ENOTVULNERABLE or whatever is suitable.

You mean add a new ENOTVULNERABLE error number?  I can't seem to find
errno.  If I need to add this, which file should it go to?

I'll keep the EINVAL temporarily in my patch till I can figure out
the ENOTSUPP and ENOTVULNERABLE usage.

Tim

> 
> And no, you don't need the MPX way because that mitigation stuff is
> unconditional and cannot be compiled out.
> 
> Thanks,
> 
> 	tglx
>