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] [day] [month] [year] [list]
Message-ID: <aIZh7F+jY8CxpuCz@x1>
Date: Sun, 27 Jul 2025 10:29:16 -0700
From: Drew Fustini <fustini@...nel.org>
To: Radim Krčmář <rkrcmar@...tanamicro.com>
Cc: Palmer Dabbelt <palmer@...belt.com>,
	Björn Töpel <bjorn@...osinc.com>,
	Alexandre Ghiti <alex@...ti.fr>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Samuel Holland <samuel.holland@...ive.com>,
	Drew Fustini <dfustini@...storrent.com>,
	Andy Chiu <andybnac@...il.com>,
	Conor Dooley <conor.dooley@...rochip.com>,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-riscv <linux-riscv-bounces@...ts.infradead.org>
Subject: Re: [PATCH] riscv: Add sysctl to control discard of vstate during
 syscall

On Mon, Jul 21, 2025 at 02:16:46PM -0700, Drew Fustini wrote:
> On Mon, Jul 21, 2025 at 02:35:38PM +0200, Radim Krčmář wrote:
> > 2025-07-18T20:39:13-07:00, Drew Fustini <fustini@...nel.org>:
> > > From: Drew Fustini <dfustini@...storrent.com>
> > >
> > > Clobbering the vector registers can significantly increase system call
> > > latency for some implementations. To mitigate this performance impact, a
> > > policy mechanism is provided to administrators, distro maintainers, and
> > > developers to control vector state discard in the form of a sysctl knob:
> > >
> > > /proc/sys/abi/riscv_v_vstate_discard
> > >
> > > Valid values are:
> > >
> > > 0: Do not discard vector state during syscall
> > > 1: Discard vector state during syscall
> > >
> > > The initial state is controlled by CONFIG_RISCV_ISA_V_VSTATE_DISCARD.
> > 
> > I think it is a bit more complicated to do this nicely...
> > Programs don't have to save/restore vector registers around syscalls
> > when compiled for riscv_v_vstate_discard=0, so running under
> > riscv_v_vstate_discard=1 would break them.
> 
> Thanks for your comments. You raise a good point that this sysctl can
> lead to the case where a program might be compiled to not save/restore
> vector registers around syscalls. That same program would not work
> correctly if the sysadmin changes riscv_v_vstate_discard to 1.
> 
> > Shouldn't we have a way to prevent riscv_v_vstate_discard=0 executable
> > from running with riscv_v_vstate_discard=1?
> 
> Yes, this does make me concerned that a program could crash as a result
> of this sysctl which would be confusing for the user as they may not
> even be aware of this sysctl. I'll have to think more about how such a
> protection could work.

After further consideration, I think that it would be appropriate for
programs that don't save/restore vector registers around syscalls to
break when riscv_v_vstate_discard=1. I believe the primary motivation
of the original change 2 years ago was to catch programs that rely on
the vector state being retained across syscalls. Thus, I think that this
behavior would be consistent with that.

Bjorn told me he is away at the moment but hopefully he can provide his
perspective when he is back.

Thanks,
Drew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ