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

[Michal Meloun]

On 14.01.2018 0:54, Marcin Wojtas wrote:
> 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
> 

Yep, I tracking this thread from start(and I have prepared similar 
mitigation).
My biggest problem with above patchset is that I'm unable to understand
why is branch predictor mitigation applied *only* for instruction
prefetch translation/permission *page* faults but not for *section*
and/or for *access* faults.
Moreover, please, take a look to Russel's response to this:
https://www.spinics.net/lists/arm-kernel/msg628022.html

Also, situation about Cortex-A15 is extremely unclear -
this pachset and TFV6 advises:

"Note that the BPIALL instruction is not effective in invalidating the
branch predictor on Cortex-A15. For that CPU, set ACTLR[0] to 1 during
early processor initialisation, and invalidate the branch predictor by 
performing an ICIALLU instruction."

But description in Cortex-A15 TRM for ID_MMFR1 branch predictor field 
contains:

[31:28] Branch predictor Indicates branch predictor management requirements.
0x2 Branch predictor requires flushing on:
- Enabling or disabling the MMU.
- Writing new data to instruction locations.
- Writing new mappings to the translation tables.
- Any change to the TTBR0, TTBR1, or TTBCR registers without a
corresponding change to the FCSE ProcessID or ContextID.

So, where is truth?
Michal