Re: [RFC PATCH 0/3] arm64: errata: Disable FWB on parts with non-ARM interconnects

From: Oliver Upton <oliver.upton@linux.dev>
To: James Morse <james.morse@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Marc Zyngier <maz@kernel.org>
Subject: Re: [RFC PATCH 0/3] arm64: errata: Disable FWB on parts with non-ARM interconnects
Date: Thu, 16 Feb 2023 18:52:40 +0000	[thread overview]
Message-ID: <Y+57eMJcg/WhMMUW@linux.dev> (raw)
In-Reply-To: <20230216182201.1705406-1-james.morse@arm.com>

Hi James,

On Thu, Feb 16, 2023 at 06:21:58PM +0000, James Morse wrote:
> Hello!
> 
> When stage1 translation is disabled, the SCTRL_E1.I bit controls the
> attributes used for instruction fetch, one of the options results in a
> non-cacheable access. A whole host of CPUs missed the FWB override
> in this case, meaning a KVM guest could fetch stale/junk data instead of
> instructions.
> 
> The workaround is to disable FWB, and do the required cache maintenance
> instead.
> 
> The good news is, this isn't a problem for systems using Arm's
> interconnect IP. The bad news is: linux can't know this. Arm knows of
> at least one platform that is affected by this erratum.
> 
> 
> This series adds support for the 'Errata Management Firmware Interface', [0]
> and queries that to determine if the CPU is affected or not.
> 
> Unfortunately, no-one has firmware that supports this new interface yet,
> and the least surprising thing to do is to enable the workaround by default,
> meaning FWB is disabled on all these cores, even for unaffected platforms.
> Platforms that are not-affected can either take a firmware-update to support
> the interface, or if the kernel they run will only run on hardware that is
> unaffected, disable the workaround at build time.

Wait, what? Is there a legitimate concern that affected systems are in
the wild today, or is there enough time for affected platforms to go and
implement the necessary firmware interface? Requiring correctly
implemented systems to explicitly opt-out seems like quite a lot more
work (w/ low likelihood) than having the one known platform go about
this the right way.

I'm rather troubled by the idea of enabling this by default on systems
that use these cores unless there really is no opportunity to
course-correct.

-- 
Thanks,
Oliver

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel