[PATCH -next v20 20/26] riscv: Add prctl controls for userspace vector management

[Palmer Dabbelt]

On Mon, 22 May 2023 02:58:45 PDT (-0700), remi at remlab.net wrote:
> Hi,
>
> Le 22 mai 2023 11:28:28 GMT+03:00, Andy Chiu <andy.chiu at sifive.com> a écrit :
>>On Sun, May 21, 2023 at 1:41 PM Rémi Denis-Courmont <remi at remlab.net> wrote:
>>>
>>>         Hi all,
>>>
>>> Le torstaina 18. toukokuuta 2023 19.19.43 EEST, vous avez écrit :
>>> > This patch add two riscv-specific prctls, to allow usespace control the
>>> > use of vector unit:
>>> >
>>> >  * PR_RISCV_V_SET_CONTROL: control the permission to use Vector at next,
>>> >    or all following execve for a thread. Turning off a thread's Vector
>>> >    live is not possible since libraries may have registered ifunc that
>>> >    may execute Vector instructions.
>>> >  * PR_RISCV_V_GET_CONTROL: get the same permission setting for the
>>> >    current thread, and the setting for following execve(s).
>>>
>>> So far the story was that if the nth bit in the ELF HWCAP auxillary vector was
>>> set, then the nth single lettered extension was supported. There is already
>>> userspace code out there that expects this of the V bit. (I know I have
>>> written such code, and I also know others did likewise.) This is how it
>>> already works for the D and F bits.
>>
>>Yes, the V bit in ELF_HWCAP becomes vague in this series.
>
>
>>> Admittedly, upstream Linux has never ever set that bit to this day. But still,
>>> if we end up with the bit set in a process that has had V support disabled by
>>> the parent (or the sysctl), existing userspace will encounter SIGILL and
>>> break.
>>>
>>> IMO, the bit must be masked not only whence the kernel lacks V support (as
>>> PATCH 02 does), but also if the process starts with V disabled.
>>
>>This is going to change ELF_HWCAP from a macro to a function. The
>>function will turn on COMPAT_HWCAP_ISA_V iff V is supported and
>>allowed. I am going to do this in v21 If this looks sane. i.e.
>>Currently I don't see other architectures which give different
>>ELF_HWCAP values on each execve. If ELF_HWCAP is not a right place to
>>encode the information then userspace has to make the prctl() call to
>>be certain on whether V is usable.
>
> I don't think the value of an auxillary vector entry can change in an existing process nor that we need that. If an application starts with V disabled, you can keep the V bit clear even if V gets enabled later on; that won't break existing userspace code, which simply won't use vectors.
>
> What does break existing userspace is setting the V bit whilst vectors are disabled.

So maybe the right answer is to just not set V at all?  The 
single-letter extensions are sort of defunct now, there's multi-letter 
sub extensions for most things, but V got ratified with those 
sub-extensions so we could just call it extra-ambiguous?

>
>
>
>>
>>>
>>> There are two ways to achieve this:
>>> 1) V is never ever set, and userspace is forced to use hwprobe() instead.
>>> 2) V is set only in processes starting with V enabled (and it's their own
>>> fault if they disabled it in future child threads).
>>
>>The prctl() interface does not allow processes to turn off V once it
>>is enabled in its current (execve) context. The process can only
>>disable V when the next execve() happens. Then, if we implement
>>ELF_HWCAP as mentioned above, the kernel will reload a new HWCAP for
>>the process. By then, the new HWCAP will have V masked since it is not
>>allowed.
>>
>>>
>>> Br,
>>>
>>> --
>>> レミ・デニ-クールモン
>>> http://www.remlab.net/
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> linux-riscv mailing list
>>> linux-riscv at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>
>>Thanks,
>>Andy
>>