On 14.01.2018 0:54, Marcin Wojtas wrote:
Hi Michal,
2018-01-12 18:15 GMT+01:00 Michal Meloun <melounmic...@gmail.com>:
On 12.01.2018 15:54, Warner Losh wrote:
On Fri, Jan 12, 2018 at 7:52 AM, Andrew Turner <and...@freebsd.org
<mailto:and...@freebsd.org>> wrote:
On 12 Jan 2018, at 14:37, Warner Losh <i...@bsdimp.com
<mailto:i...@bsdimp.com>> wrote:
On Fri, Jan 12, 2018 at 7:15 AM, Andrew Turner <and...@freebsd.org
<mailto:and...@freebsd.org>> wrote:
On 12 Jan 2018, at 14:10, Marcin Wojtas <m...@semihalf.com
<mailto:m...@semihalf.com>> wrote:
Hi Andrew,
2018-01-12 15:01 GMT+01:00 Andrew Turner <and...@freebsd.org
<mailto:and...@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
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
