Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230518161949.11203-1-andy.chiu@sifive.com> <20230518161949.11203-21-andy.chiu@sifive.com>
 <5677700.DvuYhMxLoT@basile.remlab.net>
In-Reply-To: <5677700.DvuYhMxLoT@basile.remlab.net>
From:   Andy Chiu <andy.chiu@sifive.com>
Date:   Mon, 22 May 2023 16:28:28 +0800
Message-ID: <CABgGipW9xtZp-c2xWakz+EzrMbviN_9iAEtmfx73L4TJAn3K8Q@mail.gmail.com>
Subject: Re: [PATCH -next v20 20/26] riscv: Add prctl controls for userspace
 vector management
To:     =?UTF-8?Q?R=C3=A9mi_Denis=2DCourmont?= <remi@remlab.net>
Cc:     linux-riscv@lists.infradead.org,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, May 21, 2023 at 1:41=E2=80=AFPM R=C3=A9mi Denis-Courmont <remi@reml=
ab.net> wrote:
>
>         Hi all,
>
> Le torstaina 18. toukokuuta 2023 19.19.43 EEST, vous avez =C3=A9crit :
> > 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 vecto=
r was
> set, then the nth single lettered extension was supported. There is alrea=
dy
> 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 s=
till,
> if we end up with the bit set in a process that has had V support disable=
d 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 (a=
s
> 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.

>
> 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,
>
> --
> =E3=83=AC=E3=83=9F=E3=83=BB=E3=83=87=E3=83=8B-=E3=82=AF=E3=83=BC=E3=83=AB=
=E3=83=A2=E3=83=B3
> http://www.remlab.net/
>
>
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Thanks,
Andy