Received: by 10.223.176.46 with SMTP id f43csp416077wra; Thu, 18 Jan 2018 19:43:04 -0800 (PST) X-Google-Smtp-Source: ACJfBosxp0E49f01RGlQgDJ6RdZbRhGxPomu9RYk+EnblLqj4q+PdxyGuB16/EPtVZsB9ZeC1AoQ X-Received: by 10.98.49.199 with SMTP id x190mr17320977pfx.1.1516333384103; Thu, 18 Jan 2018 19:43:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516333384; cv=none; d=google.com; s=arc-20160816; b=uTSl0I8cya+kgGkwitEAF3QkPYnT9hEW7jxewCy9vfxe9HdI/oVJ02FrXKNw10Ts/W vZkKIMBOLe1o/v6UyRTnZGqCcXfVo38lyKReECnrJ3RJaLM/ceR50Xp+Av0mimJx79At HPjur+tJfqRNsdcbCnBktoLOzhqqgqqyI+98SBpTvE9J2CzbO0VKdw34KzgAAFUmFwNq X36VBLQCPqisJeb9T8p2DBaGtvOqAWhA+6GTOpLlZESgeV2i9EIq0EiXEqJYXU2Jv7sm qoupcu92D1ZcQGjovl7UbtbYynlV4p3DpE9UPbxeoXXCUAFftjXFbhefMvjQkfp8NrWG BzfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=KiI2C1IJEmaaTuVNQ8MJ1pq02ZzV1QNr5vsj0dLZbpI=; b=DkdaxbramaVrTO1mYw8pqlH8ARSjgc6QJXRjzagU6qJZ4I/EQTUBmYMKkz30f/lc+C A/2BZYImtVtTxh/H2l74VWO6sQFBxm5QDRV37547Nf5RCqaMKpAGRm0oKeMmZf6bRIGl kYtuttaPJu9UZvHN1qpxg24dS03wz+Rz7tA6Y0Qv8PYXRq25ws39ltRSZa4pirt9r1wN fp9yoOYC1vOAqRYAzJ6FO/i7QCdAlrYDVomi6cqUyMidAkR94KNY1+UyjPRjtXM9Ghfn k9TjlbuweWD9yoJLUAQw9//Co0BybkuGN2/NZVL+dFX33lDjUK+BHN3vhWMXrTdJxh7V N77Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e15si7474382pgu.356.2018.01.18.19.42.49; Thu, 18 Jan 2018 19:43:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755479AbeASDkx (ORCPT + 99 others); Thu, 18 Jan 2018 22:40:53 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:4666 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755055AbeASDkq (ORCPT ); Thu, 18 Jan 2018 22:40:46 -0500 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id D9E66E80F09C3; Fri, 19 Jan 2018 11:40:32 +0800 (CST) Received: from [10.111.203.133] (10.111.203.133) by smtp.huawei.com (10.3.19.208) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 19 Jan 2018 11:40:26 +0800 Subject: Re: [PATCH v2 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks To: Will Deacon , Yisheng Xie References: <1515157961-20963-1-git-send-email-will.deacon@arm.com> <1515157961-20963-8-git-send-email-will.deacon@arm.com> <01c224eb-9bec-6b16-7ecf-14837cc107b6@huawei.com> <20180117100715.GA27892@arm.com> CC: , , , , , , , From: Li Kun Message-ID: Date: Fri, 19 Jan 2018 11:37:24 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20180117100715.GA27892@arm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.111.203.133] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi will, 在 2018/1/17 18:07, Will Deacon 写道: > On Wed, Jan 17, 2018 at 12:10:33PM +0800, Yisheng Xie wrote: >> Hi Will, >> >> On 2018/1/5 21:12, Will Deacon wrote: >>> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c >>> index 5f7097d0cd12..d99b36555a16 100644 >>> --- a/arch/arm64/mm/context.c >>> +++ b/arch/arm64/mm/context.c >>> @@ -246,6 +246,8 @@ asmlinkage void post_ttbr_update_workaround(void) >>> "ic iallu; dsb nsh; isb", >>> ARM64_WORKAROUND_CAVIUM_27456, >>> CONFIG_CAVIUM_ERRATUM_27456)); >>> + >>> + arm64_apply_bp_hardening(); >>> } >> post_ttbr_update_workaround was used for fix Cavium erratum 2745? so does that >> means, if we do not have this erratum, we do not need arm64_apply_bp_hardening()? >> when mm_swtich and kernel_exit? >> >> From the code logical, it seems not only related to erratum 2745 anymore? >> should it be renamed? > post_ttbr_update_workaround just runs code after a TTBR update, which > includes mitigations against variant 2 of "spectre" and also a workaround > for a Cavium erratum. These are separate issues. But AFAIU, according to the theory of spectre, we don't need to clear the BTB every time we return to user? If we enable CONFIG_ARM64_SW_TTBR0_PAN, there will be a call to arm64_apply_bp_hardening every time kernel exit to el0. kernel_exit post_ttbr_update_workaround arm64_apply_bp_hardening > > Will > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Best Regards Li Kun