svn commit: r327876 - in head/sys/arm64: arm64 include

[Marcin Wojtas]

Hi Michal,

2018-01-12 18:15 GMT+01:00 Michal Meloun <melounmichal at gmail.com>:
>
>
> On 12.01.2018 15:54, Warner Losh wrote:
>>
>>
>>
>> On Fri, Jan 12, 2018 at 7:52 AM, Andrew Turner <andrew at freebsd.org
>> <mailto:andrew at freebsd.org>> wrote:
>>
>>
>>
>>>     On 12 Jan 2018, at 14:37, Warner Losh <imp at bsdimp.com
>>>     <mailto:imp at bsdimp.com>> wrote:
>>>
>>>
>>>
>>>     On Fri, Jan 12, 2018 at 7:15 AM, Andrew Turner <andrew at freebsd.org
>>>     <mailto:andrew at freebsd.org>> wrote:
>>>
>>>
>>>
>>>>         On 12 Jan 2018, at 14:10, Marcin Wojtas <mw at semihalf.com
>>>>         <mailto:mw at semihalf.com>> wrote:
>>>>
>>>>         Hi Andrew,
>>>>
>>>>
>>>>
>>>>         2018-01-12 15:01 GMT+01:00 Andrew Turner <andrew at freebsd.org
>>>>         <mailto:andrew at freebsd.org>>:
>>>>
>>>>>         Author: andrew
>>>>>         Date: Fri Jan 12 14:01:38 2018
>>>>>         New Revision: 327876
>>>>>         URL: https://svnweb.freebsd.org/changeset/base/327876
>>>>>         <https://svnweb.freebsd.org/changeset/base/327876>
>>>>>
>>>>>         Log:
>>>>>          Workaround Spectre Variant 2 on arm64.
>>>>>
>>>>>          We need to handle two cases:
>>>>>
>>>>>          1. One process attacking another process.
>>>>>          2. A process attacking the kernel.
>>>>>
>>>>>          For the first case we clear the branch predictor state on
>>>>>         context switch
>>>>>          between different processes. For the second we do this when
>>>>>         taking an
>>>>>          instruction abort on a non-userspace address.
>>>>>
>>>>>          To clear the branch predictor state a per-CPU function
>>>>>         pointer has been
>>>>>          added. This is set by the new cpu errata code based on if
>>>>>         the CPU is
>>>>>          known to be affected.
>>>>>
>>>>>          On Cortex-A57, A72, A73, and A75 we call into the PSCI
>>>>>         firmware as newer
>>>>>          versions of this will clear the branch predictor state for us.
>>>>>
>>>>>          It has been reported the ThunderX is unaffected, however
>>>>>         the ThunderX2 is
>>>>>          vulnerable. The Qualcomm Falkor core is also affected. As
>>>>>         FreeBSD doesn't
>>>>>          yet run on the ThunderX2 or Falkor no workaround is
>>>>>         included for these CPUs.
>>>>
>>>>
>>>>         Regardless ThunderX2 / Falkor work-arounds, do I understand
>>>>         correctly
>>>>         that pure CA72 machines, such as Marvell Armada 7k/8k are
>>>>         immune to
>>>>         Variant 2 now?
>>>
>>>
>>>         It is my understanding that the A72 will be immune with this
>>>         patch and an updated Arm Trusted Firmware as documented in [1].
>>>
>>>         Andrew
>>>
>>>         [1]
>>>
>>> https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6
>>>
>>> <https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6>
>>>
>>>
>>>     Are you also working on aarch32 mitigation?
>>
>>
>>     No. I think a similar technique could be used, however as aarch32
>>     has instructions to invalidate the branch predictor these can be
>>     used directly.
>>
>>
>> That's my reading as well. It looks fairly easy to do it always, but I've
>> not researched it sufficiently.
>>
>
> I work on patches for armv6/7. But for aarch32, there is, unfortunately,
> much less information available about affective mitigation of variant 2.
> BPIALL while switching pmap is clear and we have it in code for years
> (well, BPIALL is effectively NOP for A15/A17, it must be explicitly
> enabled).
> But is not clear for me for which trap is branch predictor flush necessary.
>

As for armv7, I believe the brand new patches on top of this branch
could be helpful:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti

Best regards,
Marcin