update on the status of SP2 mitigations for Xen on Arm

update on the status of SP2 mitigations for Xen on Arm

[Stefano Stabellini]

Hi all,

This is the latest status of the SP2 mitigations for Xen on Arm. Please
note that arm32 and arm64 require different mitigations.

I have just backported the arm32 mitigation to 4.10, 4.9, 4.8 and 4.7:

- 4.10
bbd093c xen/arm32: entry: Document the purpose of r11 in the traps handler
a69a8b5 xen/arm32: Invalidate icache on guest exist for Cortex-A15
f167ebf xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
c4c0187 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
19ad8a7 xen/arm32: entry: Add missing trap_reset entry
3caf32c xen/arm32: Add missing MIDR values for Cortex-A17 and A12
df7be94 xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros

- 4.9
4d01dbc xen/arm32: entry: Document the purpose of r11 in the traps handler
22379b6 xen/arm32: Invalidate icache on guest exist for Cortex-A15
6e13ad7 xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
0d32237 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
4ba59bd xen/arm32: entry: Add missing trap_reset entry
2997c5e xen/arm32: Add missing MIDR values for Cortex-A17 and A12
751c879 xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros

- 4.8
11875b7 xen/arm32: entry: Document the purpose of r11 in the traps handler
1105f3a xen/arm32: Invalidate icache on guest exist for Cortex-A15
754345c xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
7336d0d xen/arm32: Add skeleton to harden branch predictor aliasing attacks
cf95bba xen/arm32: entry: Add missing trap_reset entry
a586cbd xen/arm32: Add missing MIDR values for Cortex-A17 and A12
6082e3b xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros

- 4.7
f50ea84 xen/arm32: entry: Document the purpose of r11 in the traps handler
de3bdaa xen/arm32: Invalidate icache on guest exist for Cortex-A15
766990b xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
4ac0229 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
bafd63f xen/arm32: entry: Add missing trap_reset entry
d5bb425 xen/arm32: Add missing MIDR values for Cortex-A17 and A12
003ec3e xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros


The arm64 backports have been in the staging trees for a while, see:
https://marc.info/?l=xen-devel&m=151690105623579

Julien posted another series to improve the SP2 mitigation for arm64:
https://marc.info/?l=xen-devel&m=151783688420038
It is not yet reviewed. This second series is highly desirable, as it
uses better firmware interfaces for the mitigation.

At present, Xen is using a PSCI get_version call (it is a call to the
PSCI firmware) for the mitigation. It relies on the firmware cleaning
the branch predictor cache in the implementation of the get_version
call. However, it appers that get_version doesn't actually do the
expected task on most arm64 platforms. Hence, the need for a new series
and a better firmware call. Julien, feel free to add more details here.

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: update on the status of SP2 mitigations for Xen on Arm

[Julien Grall]

On 07/02/18 20:14, Stefano Stabellini wrote:
> Hi all,

Hi,

I'd like to make some clarifications on what has been merged in Xen so 
far and the state of SP2.

> 
> This is the latest status of the SP2 mitigations for Xen on Arm. Please
> note that arm32 and arm64 require different mitigations.
> 
> I have just backported the arm32 mitigation to 4.10, 4.9, 4.8 and 4.7:

What you backported is a framework to enable per processor mitigation. 
Mitigation for Cortex-A15 (providing a firmware upgraded), Cortex-A17 
and Cortex-A12 has been added which covered the Arm designed processor.

This does *not* cover any processor that have not been designed by Arm 
and potentially affected by SP2.

Furthermore, while the framework is able to deal with platform with 
heterogeneous processors (e.g big.LITTLE), Xen does not expose correctly 
that information to the guest. This means that guest (such as Linux) 
will still be vulnerable to SP2. I suggested a patch to disable 
big.LITTLE on Xen for the time being (see [1]).

> 
> - 4.10
> bbd093c xen/arm32: entry: Document the purpose of r11 in the traps handler
> a69a8b5 xen/arm32: Invalidate icache on guest exist for Cortex-A15
> f167ebf xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
> c4c0187 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
> 19ad8a7 xen/arm32: entry: Add missing trap_reset entry
> 3caf32c xen/arm32: Add missing MIDR values for Cortex-A17 and A12
> df7be94 xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros
> 
> - 4.9
> 4d01dbc xen/arm32: entry: Document the purpose of r11 in the traps handler
> 22379b6 xen/arm32: Invalidate icache on guest exist for Cortex-A15
> 6e13ad7 xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
> 0d32237 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
> 4ba59bd xen/arm32: entry: Add missing trap_reset entry
> 2997c5e xen/arm32: Add missing MIDR values for Cortex-A17 and A12
> 751c879 xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros
> 
> - 4.8
> 11875b7 xen/arm32: entry: Document the purpose of r11 in the traps handler
> 1105f3a xen/arm32: Invalidate icache on guest exist for Cortex-A15
> 754345c xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
> 7336d0d xen/arm32: Add skeleton to harden branch predictor aliasing attacks
> cf95bba xen/arm32: entry: Add missing trap_reset entry
> a586cbd xen/arm32: Add missing MIDR values for Cortex-A17 and A12
> 6082e3b xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros
> 
> - 4.7
> f50ea84 xen/arm32: entry: Document the purpose of r11 in the traps handler
> de3bdaa xen/arm32: Invalidate icache on guest exist for Cortex-A15
> 766990b xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
> 4ac0229 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
> bafd63f xen/arm32: entry: Add missing trap_reset entry
> d5bb425 xen/arm32: Add missing MIDR values for Cortex-A17 and A12
> 003ec3e xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros
> 
> 
> The arm64 backports have been in the staging trees for a while, see:
> https://marc.info/?l=xen-devel&m=151690105623579

See remark as for arm32 mitigation here.

> 
> Julien posted another series to improve the SP2 mitigation for arm64:
> https://marc.info/?l=xen-devel&m=151783688420038
> It is not yet reviewed. This second series is highly desirable, as it
> uses better firmware interfaces for the mitigation.
> 
> At present, Xen is using a PSCI get_version call (it is a call to the
> PSCI firmware) for the mitigation. It relies on the firmware cleaning
> the branch predictor cache in the implementation of the get_version
> call. However, it appers that get_version doesn't actually do the
> expected task on most arm64 platforms. Hence, the need for a new series
> and a better firmware call. Julien, feel free to add more details here.

PSCI get_version was the first band-aid suggested for a generic way to 
invalidate branch predictor on Arm64 platform. It *never* relied on 
current firmware implementation to invalidate the branch predictor. It 
was relying on affected vendor to update their firmware implementation 
to invalidate branch predictor on PSCI get_version call.

Arm has published a new version of SMCCC specification (1.1) that 
provides an optimised calling convention and optional, discoverable 
support for mitigating CVE-2017-5715 (XSA-254 SP2).

The series I posted covers the implementation of SMCCC 1.1 for the 
guests. I am still working on the host side (should be posted soon). For 
the host sides, the mitigation will only be applied on *known* affected 
processors. The vendors will have to send a patch if there processors 
and requires mitigation for SP2 (even if they are using SMCCC 1.1 .

None of the Linux release will contain the PSCI get_version call (see 
[2]) and it is in my plan to drop it from Xen as well.

Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2018-01/msg02756.html
[2] https://patchwork.kernel.org/patch/10203701/

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel