From owner-svn-src-head@freebsd.org Sun Jan 14 04:44:36 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8944BE79A37; Sun, 14 Jan 2018 04:44:36 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FA3C6AAF3; Sun, 14 Jan 2018 04:44:36 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id 143so18939320wma.5; Sat, 13 Jan 2018 20:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zg2JfInObg6h+D9H8+yjvN490UmRvl+rgls3Ho/5Ud8=; b=RrYdEZRM5Ejh2AU/ddAyuMtmJIjAXqDlyn1ST9MW9NaSFDsDQGb624YBhNGyRwkceW AvcdHJ2xjBJEka1A8vBfg/G5+FEjxKto9jXaJjUjdQe8BMdTM3y1n+RQxGljZhLgR2xF jPIMmy/7aYOC5FUqO+7zLewVZWvNwDnBdAcCFh+eJJMpLOsqwwrc42mkHXc37/esQX3G XDsfD8viK1vthox0LcVDuZ0Otu/HlolwVdZ5bdwiROLzU+/St8lIv7Ih7WQqv+3wGo3N 7NlaKNpa03rv03aICHdj7JYesdYpqld42zahQ+yFwhOtRxJyt6PIVFrwcsPyGOe73emZ 5bFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zg2JfInObg6h+D9H8+yjvN490UmRvl+rgls3Ho/5Ud8=; b=i973ZqTCDYr+ACrY+OcERm28zTmYwzx2nAE8hHbkMR0ulHxs2zwR5jAOZcp1tDdH7m IyRuUf76bW0Wj9rWSMC6FMCR7cUC5n4z0sO2qMM367bNcTDm2LDvO3hEa3X509Xb8qAo KqqIizxYrjEOBy9OcEcq7z7kKRtBoVtxBqdXBxBn6SSre0KOY5l3vU2mjUgRm8t5T5yv 0JmQmkQlcU/nSRHH/V17MF8wB6Vp8ivK8Wc/kSTw7y0AHYjZ9TJzBPjPk1woZib0qZHd AJms7JOZWYTBQBVG2ZmLidwLuk8Q1EgNGjmOWWnSaH9Mo5nsIS5rCUX7Qk36iK1rdeXG 9OkQ== X-Gm-Message-State: AKwxytcvvK8zIRACKIOQqoCC1vewvCi8GsG1sbtfcDBDrXRcCkOYJCZq SHXGATpcPPMK2+/teOVnKLyb+ApVznA= X-Google-Smtp-Source: ACJfBotHZB3XmQ54hf8m8GchFaOFkvxlYPagC4+/+5i/tP7t9T03lWUM8pAvp0HvgUmQLg7bZxLNzg== X-Received: by 10.28.13.140 with SMTP id 134mr7190475wmn.106.1515905073754; Sat, 13 Jan 2018 20:44:33 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id 11sm4201649wmd.33.2018.01.13.20.44.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jan 2018 20:44:33 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: svn commit: r327876 - in head/sys/arm64: arm64 include To: Marcin Wojtas Cc: Warner Losh , Andrew Turner , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201801121401.w0CE1cW4058239@repo.freebsd.org> <187e75c7-343f-aea6-cb59-61c77fd64023@freebsd.org> Message-ID: <537c83c6-8e67-0861-207c-de5aebe4ef49@freebsd.org> Date: Sun, 14 Jan 2018 05:44:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 04:44:36 -0000 On 14.01.2018 0:54, Marcin Wojtas wrote: > Hi Michal, > > 2018-01-12 18:15 GMT+01:00 Michal Meloun : >> >> >> On 12.01.2018 15:54, Warner Losh wrote: >>> >>> >>> >>> On Fri, Jan 12, 2018 at 7:52 AM, Andrew Turner >> > wrote: >>> >>> >>> >>>> On 12 Jan 2018, at 14:37, Warner Losh >>> > wrote: >>>> >>>> >>>> >>>> On Fri, Jan 12, 2018 at 7:15 AM, Andrew Turner >>> > wrote: >>>> >>>> >>>> >>>>> On 12 Jan 2018, at 14:10, Marcin Wojtas >>>> > wrote: >>>>> >>>>> Hi Andrew, >>>>> >>>>> >>>>> >>>>> 2018-01-12 15:01 GMT+01:00 Andrew Turner >>>> >: >>>>> >>>>>> Author: andrew >>>>>> Date: Fri Jan 12 14:01:38 2018 >>>>>> New Revision: 327876 >>>>>> URL: 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 >>>> >>>> >>>> >>>> >>>> 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