On Thu, May 24, 2018 at 01:49:51PM +0100, Marc Zyngier wrote:

On 24/05/18 13:30, Russell King - ARM Linux wrote:

quoted

On Thu, May 24, 2018 at 01:03:50PM +0100, Marc Zyngier wrote:

quoted

On 23/05/18 20:45, Russell King - ARM Linux wrote:

quoted

On Tue, May 22, 2018 at 06:24:13PM +0100, Marc Zyngier wrote:

quoted

On 21/05/18 12:45, Russell King wrote:

quoted

+#ifdef CONFIG_ARM_PSCI
+	if (psci_ops.smccc_version != SMCCC_VERSION_1_0) {
+		struct arm_smccc_res res;
+
+		switch (psci_ops.conduit) {
+		case PSCI_CONDUIT_HVC:
+			arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+					  ARM_SMCCC_ARCH_WORKAROUND_1, &res);
+			if ((int)res.a0 < 0)
+				break;

I just realised that there is a small, but significant difference
between this and the arm64 version: On arm64, we have a table of
vulnerable implementations, and we try the mitigation on a per-cpu
basis. Here, you entirely rely on the firmware to discover whether the
CPU needs mitigation or not. You then need to check for a return value
of 1, which indicates that although the mitigation is implemented, it is
not required on this particular CPU.

Okay, so digging further into the documentation seems to suggest that we
only need to check the firmware for A72 and A57 CPUs, and given this
statement:

"Arm recommends that the caller only call this on PEs for which a
 firmware based mitigation of CVE-2017-5715 is required, or where
 a local workaround is infeasible."

it seems that the right answer is to ignore the PSCI based methods when
we have anything but these CPUs.  Do you agree?

For CPUs that are produced by ARM, I agree. I don't know about CPUs
produced by ARM licensees though, so I'd rather use the opposite logic:
Use the firmware unless the CPU is one of those that can be easily
mitigated at EL1 (or isn't affected).

The "or isn't affected" is the difficult bit - I guess we could match
on the CPU vendor field though, and just reject all ARM CPUs that
aren't explicitly listed as having a problem.

That seems sensible. ARM has published an exhaustive status for all its
cores, which we can trust. For architecture licensees, I'm not aware of
such a list, but I'd expect them to communicate one if they were affected.

It's not that simple - there's an exhaustive list for those affected
cores, but it says that cores which aren't listed are unaffected.

If we want to explicitly list each core, we need a complete list of
both affected and unaffected cores to ensure that none are missed.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up