Spectre and Meltdown: ARM mitigates cache speculation side-channel vulnerability
Available here, the list includes Arm Cortex-R7, R8, A8, A9, A15, A17, A57, A72, A73 and A75, although the firm points out Cortex-Rx processors are used in closed environments unlikely to be accessible to malware.
- For ‘version 1’ of the attacks the advice is to search user code for specified code snippets and then modify them in a specified way using an up-to-date compiler. (click link above for details)
- For versions 2 and 3 it is to apply all kernel patches (provided by Arm) and apply all Arm ‘trusted firmware’ patches. (click link above for details)
The description of the attach mechanism is published in Arm white paper ‘Cache Speculation Side-channels‘, which is technically detailed, but in a more accessible form than the exacting computer science descriptions linked to in this article.
According to the white paper introduction
The basic principle behind cache timing side-channels is that the pattern of allocations into the cache, and, in particular, which cache sets have been used for the allocation, can be determined by measuring the time taken to access entries that were previously in the cache, or by measuring the time to access the entries that have been allocated. This then can be used to determine which addresses have been allocated into the cache.
The novelty of speculation-based cache timing side-channels is their use of speculative memory reads. Speculative memory reads are typical of advanced micro-processors and part of the overall functionality which enables very high performance. By performing speculative memory reads to cacheable locations beyond an architecturally unresolved branch (or other change in program flow), and, further, the result of those reads can themselves be used to form the addresses of further speculative memory reads.
These speculative reads cause allocations of entries into the cache whose addresses are indicative of the values of the first speculative read. This becomes an exploitable side-channel if untrusted code is able to control the speculation in such a way it causes a first speculative read of location which would not otherwise be accessible at that untrusted code. But the effects of the second speculative allocation within the caches can be measured by that untrusted code.