Date: Sun, 14 Jan 2018 05:44:32 +0100 From: Michal Meloun <melounmichal@gmail.com> To: Marcin Wojtas <mw@semihalf.com> Cc: Warner Losh <imp@bsdimp.com>, Andrew Turner <andrew@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327876 - in head/sys/arm64: arm64 include Message-ID: <537c83c6-8e67-0861-207c-de5aebe4ef49@freebsd.org> In-Reply-To: <CAPv3WKcOo7M%2BH25mm_%2BLR3r9h8VGpFj9%2BZMLXUx3qxHy=E5arw@mail.gmail.com> References: <201801121401.w0CE1cW4058239@repo.freebsd.org> <CAPv3WKcESa_AL=R-BFwef2GXxHcYsnmbUOV3Zx5qL8WdMS-o3Q@mail.gmail.com> <FEDCB2AD-AFF1-4C10-9191-76601A66BC1D@freebsd.org> <CANCZdfpfEJcxdGeya1_6jT=RKdT8VUw%2BY7Ma2Z=%2Bk6DY_XaG4g@mail.gmail.com> <AB05E4EE-0B08-43F7-AA89-8B104B99E6B2@freebsd.org> <CANCZdfo8r7WgKFhi-=iZ=gThyDPi2mmNHtgMGuXxvi2oKm53MQ@mail.gmail.com> <187e75c7-343f-aea6-cb59-61c77fd64023@freebsd.org> <CAPv3WKcOo7M%2BH25mm_%2BLR3r9h8VGpFj9%2BZMLXUx3qxHy=E5arw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14.01.2018 0:54, Marcin Wojtas wrote: > Hi Michal, > > 2018-01-12 18:15 GMT+01:00 Michal Meloun <melounmichal@gmail.com>: >> >> >> On 12.01.2018 15:54, Warner Losh wrote: >>> >>> >>> >>> On Fri, Jan 12, 2018 at 7:52 AM, Andrew Turner <andrew@freebsd.org >>> <mailto:andrew@freebsd.org>> wrote: >>> >>> >>> >>>> On 12 Jan 2018, at 14:37, Warner Losh <imp@bsdimp.com >>>> <mailto:imp@bsdimp.com>> wrote: >>>> >>>> >>>> >>>> On Fri, Jan 12, 2018 at 7:15 AM, Andrew Turner <andrew@freebsd.org >>>> <mailto:andrew@freebsd.org>> wrote: >>>> >>>> >>>> >>>>> On 12 Jan 2018, at 14:10, Marcin Wojtas <mw@semihalf.com >>>>> <mailto:mw@semihalf.com>> wrote: >>>>> >>>>> Hi Andrew, >>>>> >>>>> >>>>> >>>>> 2018-01-12 15:01 GMT+01:00 Andrew Turner <andrew@freebsd.org >>>>> <mailto:andrew@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?537c83c6-8e67-0861-207c-de5aebe4ef49>