From: "Rémi Denis-Courmont" <remi@remlab.net>
To: linux-riscv@lists.infradead.org
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next v20 20/26] riscv: Add prctl controls for userspace vector management
Date: Sun, 21 May 2023 08:38:12 +0300 [thread overview]
Message-ID: <5677700.DvuYhMxLoT@basile.remlab.net> (raw)
In-Reply-To: <20230518161949.11203-21-andy.chiu@sifive.com>
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.
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.
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).
Br,
--
レミ・デニ-クールモン
http://www.remlab.net/
next prev parent reply other threads:[~2023-05-21 5:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230518161949.11203-1-andy.chiu@sifive.com>
[not found] ` <20230518161949.11203-25-andy.chiu@sifive.com>
2023-05-21 5:20 ` [PATCH -next v20 24/26] riscv: Add documentation for Vector Rémi Denis-Courmont
[not found] ` <20230518161949.11203-21-andy.chiu@sifive.com>
2023-05-21 5:38 ` Rémi Denis-Courmont [this message]
2023-05-22 8:28 ` [PATCH -next v20 20/26] riscv: Add prctl controls for userspace vector management Andy Chiu
2023-05-22 9:58 ` Rémi Denis-Courmont
2023-05-24 0:18 ` Palmer Dabbelt
2023-05-24 9:25 ` Andy Chiu
2023-05-24 16:16 ` Rémi Denis-Courmont
2023-05-30 14:14 ` Andy Chiu
2023-05-24 16:13 ` Rémi Denis-Courmont
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5677700.DvuYhMxLoT@basile.remlab.net \
--to=remi@remlab.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox