Re: [PATCH 09/14] ARM: spectre-v2: add PSCI based hardening

[Russell King - ARM Linux <linux@armlinux.org.uk>]

On Thu, May 24, 2018 at 01:49:51PM +0100, Marc Zyngier wrote:
> On 24/05/18 13:30, Russell King - ARM Linux wrote:
> > On Thu, May 24, 2018 at 01:03:50PM +0100, Marc Zyngier wrote:
> >> On 23/05/18 20:45, Russell King - ARM Linux wrote:
> >>> On Tue, May 22, 2018 at 06:24:13PM +0100, Marc Zyngier wrote:
> >>>> On 21/05/18 12:45, Russell King wrote:
> >>>>> +#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