linux-kernel - Re: [PATCH v3 0/4] riscv: Separate vendor extensions from standard extensions

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: <Zp6/1CzztAOT51yU@ghost>
Date: Mon, 22 Jul 2024 13:23:48 -0700
From: Charlie Jenkins <charlie@...osinc.com>
To: Andrew Jones <ajones@...tanamicro.com>
Cc: Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>,
	Conor Dooley <conor.dooley@...rochip.com>,
	Evan Green <evan@...osinc.com>, Andy Chiu <andy.chiu@...ive.com>,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Yu Chien Peter Lin <peterlin@...estech.com>
Subject: Re: [PATCH v3 0/4] riscv: Separate vendor extensions from standard
 extensions

On Mon, Jul 22, 2024 at 02:32:49PM -0500, Andrew Jones wrote:
> On Fri, Jul 19, 2024 at 09:15:17AM GMT, Charlie Jenkins wrote:
> > All extensions, both standard and vendor, live in one struct
> > "riscv_isa_ext". There is currently one vendor extension, xandespmu, but
> > it is likely that more vendor extensions will be added to the kernel in
> > the future. As more vendor extensions (and standard extensions) are
> > added, riscv_isa_ext will become more bloated with a mix of vendor and
> > standard extensions.
> 
> But the mix doesn't hurt and with everything in one place it makes it easy
> to know where to look.
> 
> > 
> > This also allows each vendor to be conditionally enabled through
> > Kconfig.
> 
> We can do that anyway by adding an extension menu for each vendor. If we
> don't want a vendor's extensions bloating the array then we just need
> some #ifdefs, e.g.
> 
> @@ -405,7 +405,9 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
>         __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
>         __RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT),
>         __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
> +#ifdef RISCV_ISA_VENDOR_EXT_ANDES
>         __RISCV_ISA_EXT_DATA(xandespmu, RISCV_ISA_EXT_XANDESPMU),
> +#endif
>  };
> 
> 
> So, I'm not convinced we want the additional complexity of vendor
> extension arrays, but maybe I'm missing something.
> 
> Thanks,
> drew

Vendor extensions are non-standard behavior, so this is largely an
organizational effort. A benefit this provides is to delegate
maintainership of vendor extensions to the vendor. Additionally, this
separation of vendor extensions prevents changes to vendor extensions
from affecting standard extensions and vice versa. 

Another motivation for this is that I expect vendor extensions to be
temporary fixes in a lot of cases. A good example is xtheadvector where
a previous version of the ratified vector spec was implemented. Another
case is vendors creating vendor extensions while waiting for RVI
ratification. This will cause these eventually-to-be-deprecated
extensions to pollute the namespace and require shuffling around of the
standard isa lists. When it's an internal structure it is less relevant,
but it is a bigger risk when it comes to hwprobe. Allowing these kinds
of vendor extensions into hwprobe runs the risk of causing a sparse key
space. We may end up with many dead bits for deprecated vendor
extensions that will never be able to be removed to maintain backward
compatibility. Having the vendor extensions split across vendors
streamlines the hwprobe implementation.

- Charlie