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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <5677700.DvuYhMxLoT@basile.remlab.net>
Date:   Sun, 21 May 2023 08:38:12 +0300
From:   Rémi Denis-Courmont <remi@...lab.net>
To:     linux-riscv@...ts.infradead.org
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next v20 20/26] riscv: Add prctl controls for userspace vector
 management

	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/