linux-kernel - Re: [PATCH v2 4/6] RISC-V: Detect unaligned vector accesses supported.

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]

Date: Fri, 21 Jun 2024 10:58:16 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Charlie Jenkins <charlie@...osinc.com>
Cc: Conor Dooley <conor.dooley@...rochip.com>,
	Jesse Taube <jesse@...osinc.com>, linux-riscv@...ts.infradead.org,
	Jonathan Corbet <corbet@....net>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>, Conor Dooley <conor@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Clément Léger <cleger@...osinc.com>,
	Evan Green <evan@...osinc.com>,
	Andrew Jones <ajones@...tanamicro.com>,
	Xiao Wang <xiao.w.wang@...el.com>, Andy Chiu <andy.chiu@...ive.com>,
	Greentime Hu <greentime.hu@...ive.com>,
	Björn Töpel <bjorn@...osinc.com>,
	Heiko Stuebner <heiko@...ech.de>,
	Costa Shulyupin <costa.shul@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Baoquan He <bhe@...hat.com>, Anup Patel <apatel@...tanamicro.com>,
	Zong Li <zong.li@...ive.com>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	Alexandre Ghiti <alexghiti@...osinc.com>,
	"Gustavo A. R. Silva" <gustavoars@...nel.org>,
	Erick Archer <erick.archer@....com>,
	Joel Granados <j.granados@...sung.com>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 4/6] RISC-V: Detect unaligned vector accesses
 supported.

On Fri, Jun 21, 2024 at 10:18:23AM -0700, Charlie Jenkins wrote:
> > Additionally, what are we doing in the kernel if we detect that
> > misaligned stuff isn't supported? Are we going to mandate that kernel
> > code is aligned only, disable in-kernel vector or some other mechanism
> > to make sure that things like crypto code don't have/introduce code
> > that'll not run on these systems?
> 
> UNSUPPORTED will still be set by the quick probe so it would be possible
> for the kernel/userspace to avoid running misaligned vector when it's
> unsupported. Any kernel methods would probably want to always run
> aligned vector unless misaligned support was determined to be FAST
> anyway, I am doubtful that code will have different optimizations for
> FAST, SLOW, and UNSUPPORTED but it is possible. 
> 
> I would prefer consistency between scalar and vector misaligned support,
> but this is not a deal breaker for this patch. I am not convinced it is
> the best choice, but I am okay with leaving this option in the kernel.
> 

Note that most of the vector crypto code (in arch/riscv/crypto/) assumes that
vector misaligned accesses are supported.  Many of the RISC-V vector crypto
instructions require using SEW=32 or SEW=64, and as a result, loads and stores
of data can be misaligned unless the code changes the SEW to 8 and back again,
which would be inefficient and add extra complexity.  I don't anticipate
workarounds for CPUs that couldn't be bothered to support misaligned accesses
being added.  So what we'll probably have to do is just disable the vector
crypto algorithms if the CPU doesn't support misaligned accesses...

- Eric