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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2621691.14T4csFsIl@basile.remlab.net>
Date:   Wed, 24 May 2023 19:13:10 +0300
From:   Rémi Denis-Courmont <remi@...lab.net>
To:     linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Cc:     andy.chiu@...ive.com, Palmer Dabbelt <palmer@...belt.com>
Subject: Re: [PATCH -next v20 20/26] riscv: Add prctl controls for userspace vector
 management

Le keskiviikkona 24. toukokuuta 2023, 3.18.26 EEST Palmer Dabbelt a écrit :
> > 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?

That is one possibility that I can live, although it feels unnecessarily user-
hostile compared to setting it only if the process _started_ with V enabled.

> 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?

Maybe; I must admit I have zero visibility to RVI inner workings. At least C, 
D and F bits could work for JIT use cases, I suppose. E and M are totally 
impractical to support. G, I, X and Z cannot are already wasted by the design, 
and I guess we will now waste all 16 others.

But as for V, what is the user-space story for the prctl()? Who is intended to 
enablet V mode? If there is no clear story, it is all but guaranteed that 
random libraries will call it, and just _blindly_ assume that there is enough 
stack space for signal handling. If so, then there is not much point having a 
prctl() in the first place; might as well stick to just a kernel Kconfig with no 
runtime configuration.

-- 
Rémi Denis-Courmont
http://www.remlab.net/