linux-kernel - Re: [PATCH 02/19] riscv: cpufeature: Fix thead vector hwcap removal

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, 12 Apr 2024 11:25:47 +0100
From: Conor Dooley <conor.dooley@...rochip.com>
To: Charlie Jenkins <charlie@...osinc.com>
CC: Conor Dooley <conor@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Paul Walmsley
	<paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou
	<aou@...s.berkeley.edu>, Guo Ren <guoren@...nel.org>, Conor Dooley
	<conor+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>, Jernej Skrabec
	<jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>, Evan Green
	<evan@...osinc.com>, Clément Léger
	<cleger@...osinc.com>, Jonathan Corbet <corbet@....net>, Shuah Khan
	<shuah@...nel.org>, <linux-riscv@...ts.infradead.org>,
	<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Palmer Dabbelt
	<palmer@...osinc.com>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-sunxi@...ts.linux.dev>, <linux-doc@...r.kernel.org>,
	<linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH 02/19] riscv: cpufeature: Fix thead vector hwcap removal

On Thu, Apr 11, 2024 at 09:11:08PM -0700, Charlie Jenkins wrote:
> The riscv_cpuinfo struct that contains mvendorid and marchid is not
> populated until all harts are booted which happens after the DT parsing.
> Use the vendorid/archid values from the DT if available or assume all
> harts have the same values as the boot hart as a fallback.
> 
> Fixes: d82f32202e0d ("RISC-V: Ignore V from the riscv,isa DT property on older T-Head CPUs")

If this is our only use case for getting the mvendorid/marchid stuff
from dt, then I don't think we should add it. None of the devicetrees
that the commit you're fixing here addresses will have these properties
and if they did have them, they'd then also be new enough to hopefully
not have "v" either - the issue is they're using whatever crap the
vendor shipped.
If we're gonna get the information from DT, we already have something
that we can look at to perform the disable as the cpu compatibles give
us enough information to make the decision.

I also think that we could just cache the boot CPU's marchid/mvendorid,
since we already have to look at it in riscv_fill_cpu_mfr_info(), avoid
repeating these ecalls on all systems.

Perhaps for now we could just look at the boot CPU alone? To my
knowledge the systems that this targets all have homogeneous
marchid/mvendorid values of 0x0.

> Signed-off-by: Charlie Jenkins <charlie@...osinc.com>

> @@ -514,12 +521,23 @@ static void __init riscv_fill_hwcap_from_isa_string(unsigned long *isa2hwcap)
>  				pr_warn("Unable to find \"riscv,isa\" devicetree entry\n");
>  				continue;
>  			}
> +			if (of_property_read_u64(node, "riscv,vendorid", &this_vendorid) < 0) {
> +				pr_warn("Unable to find \"riscv,vendorid\" devicetree entry, using boot hart mvendorid instead\n");

This should 100% not be a warning, it's not a required property in the
binding.

Cheers,
Conor.

> +				this_vendorid = boot_vendorid;
> +			}

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)