Date: Sun, 14 Jan 2018 00:54:17 +0100 From: Marcin Wojtas <mw@semihalf.com> To: mmel@freebsd.org 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: <CAPv3WKcOo7M%2BH25mm_%2BLR3r9h8VGpFj9%2BZMLXUx3qxHy=E5arw@mail.gmail.com> In-Reply-To: <187e75c7-343f-aea6-cb59-61c77fd64023@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 Best regards, Marcin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPv3WKcOo7M%2BH25mm_%2BLR3r9h8VGpFj9%2BZMLXUx3qxHy=E5arw>