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;
From:   =?ISO-8859-1?Q?R=E9mi?= 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
Message-ID: <5677700.DvuYhMxLoT@basile.remlab.net>
Organization: Remlab
In-Reply-To: <20230518161949.11203-21-andy.chiu@sifive.com>
References: <20230518161949.11203-1-andy.chiu@sifive.com>
 <20230518161949.11203-21-andy.chiu@sifive.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

	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/