On Mon, Aug 19, 2024 at 04:06:08PM -0700, Charlie Jenkins wrote: > On Tue, Aug 13, 2024 at 04:55:27PM +0100, Conor Dooley wrote: > > On Mon, Aug 12, 2024 at 05:45:30PM -0700, Charlie Jenkins wrote: > > > On Fri, Aug 09, 2024 at 11:31:15PM +0100, Conor Dooley wrote: > > > > On Tue, Aug 06, 2024 at 05:31:36PM -0700, Charlie Jenkins wrote: > > > > > xtheadvector is a custom extension that is based upon riscv vector > > > > > version 0.7.1 [1]. All of the vector routines have been modified to > > > > > support this alternative vector version based upon whether xtheadvector > > > > > was determined to be supported at boot. > > > > > > > > > > vlenb is not supported on the existing xtheadvector hardware, so a > > > > > devicetree property thead,vlenb is added to provide the vlenb to Linux. > > > > > > > > > > There is a new hwprobe key RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 that is > > > > > used to request which thead vendor extensions are supported on the > > > > > current platform. This allows future vendors to allocate hwprobe keys > > > > > for their vendor. > > > > > > > > > > Support for xtheadvector is also added to the vector kselftests. > > > > > > > > So uh, since noone seems to have brought it up, in the light of the issues > > > > with thead's vector implementation, (https://ghostwriteattack.com/) do we > > > > want to enable it at all? > > > > > > I can make it clear in the kconfig that xtheadvector is succeptible to > > > this attack and that it should be enabled with caution. I think we > > > should let people that understand the risk to enable it. > > > > I think the clearest way might be "depends on BROKEN"? > > Sorry for the delay, I am not sure if BROKEN is the best way of doing > this. There is the generic CPU_MITIGATIONS config that I think we should > use to handle this at boot time. This would allow generic kernels to be > used on the platform, but a kernel config of "mitigations=off" would > allow xtheadvector to be enabled. I'll look into this a bit more and > send out a patch. Palmer merged a patch into for-next to enable > GENERIC_CPU_VULNERABILITIES for riscv so I will add ghostwrite there > as well. Palmer also pointed out to me last week that not all implementations of xtheadvector actually have the flaw, so it makes sense to not depend on BROKEN. We should figure out exactly which CPUs are and are not vulnerable (Guo Ren hopefully will know) and permit enabling it without "mitagations=off" on the CPUs that are not vulnerable. Thanks, Conor.
Attachment:
signature.asc
Description: PGP signature
