> Date: Thu, 3 May 2018 08:19:01 +0100 > From: Dimitris Papastamos <s...@2f30.org>
Hi Dimitris, > On Tue, May 01, 2018 at 11:55:00AM +0200, Mark Kettenis wrote: > > So after adding a quick hack to mitigate Spectre variant 2 to ARM > > Trusted Firmware (ATF), ARM actually designed a proper solution that > > minimizes the performance loss and makes the presence of the > > workaround detectable. This is all documented in an update of the SMC > > Calling Convention (SMCCC) standard. > > > > The diff below implements support for this solution while keeping > > support for the hack. While ARM strongly suggests vendors to update > > to a version of ATF that implements SMCCC 1.1 the current ATF for the > > Marvell ARMADA 8040 hasn't been updated yet (but does include the > > initial hack). > > > > Unfortunately the SMCCC 1.1 implementation in ATF doesn't quite > > implement the spec. As a result we have to check whether the > > workaround is implemented by issuing the relevant calls on each of the > > CPUs that might be affected. This is important for big.LITTLE designs > > such as the RK3399 that include both Cortex-A53 cores that aren't > > vulnerable and Cortex-A72 cores that are. > > Can you explain a bit the inconsistency between the spec and the TF > implementation? If there is an issue in the TF implementation I can > fix it. > > On a big.LITTLE system the expected behaviour is for > SMCCC_ARCH_FEATURES() to return 1 for the unaffected cores > (Cortex-A53) and 0 for the affected cores (Cortex-A72). The call will > only return -1 if TF is built without mitigation support for > CVE-2017-5715. Looks like I managed to confuse myself and drew the wrong conclusion from the description of SMCCC_ARCH_WORKAROUND_1 in section 2.2.4.4: In heterogeneous systems with some PEs that require mitigation and others that do not, the firmware must provide a safe implementation of this function on all PEs. I now notice that 2.2.4.2 explicitly spells out the results of the SMCCC_ARCH)FEATURES call that matches the behaviour you indicate above and doesn't actually contradict what's written in 2.2.4.4. I'll adjust the comments in the OpenBSD code. Thanks for enlightening me! > You might also want this patch: > > https://github.com/ARM-software/arm-trusted-firmware/commit/59dc4ef48757e4de2dc2de13d13e43acd5d91aa0#diff-3de7e205aa9233a71ea7940aae6579fe > That certainly makes the code easier to understand. I'll see if I can trick the Marvell folks into backporting that to their TF fork. Thanks, Mark P.S. I'm still thinking about "leveraging" trusted firmware to improve the security of OpenBSD. I have some ideas, but no concrete plans yet to implement anything.
