From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B565C63798 for ; Thu, 19 Nov 2020 12:46:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F30E5246F3 for ; Thu, 19 Nov 2020 12:46:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727235AbgKSMqa (ORCPT ); Thu, 19 Nov 2020 07:46:30 -0500 Received: from foss.arm.com ([217.140.110.172]:56360 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726790AbgKSMq3 (ORCPT ); Thu, 19 Nov 2020 07:46:29 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6039A1396; Thu, 19 Nov 2020 04:46:28 -0800 (PST) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EFEED3F718; Thu, 19 Nov 2020 04:46:25 -0800 (PST) Subject: Re: [PATCH v4 1/2] arm64: kvm: Save/restore MTE registers To: Catalin Marinas Cc: Marc Zyngier , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , Mark Rutland , Thomas Gleixner , qemu-devel@nongnu.org, Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Peter Maydell , Haibo Xu , Andrew Jones References: <20201026155727.36685-1-steven.price@arm.com> <20201026155727.36685-2-steven.price@arm.com> <98eaa539-0ae8-ce4c-8886-3040542ede80@arm.com> From: Steven Price Message-ID: Date: Thu, 19 Nov 2020 12:45:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/11/2020 17:02, Catalin Marinas wrote: > On Wed, Nov 18, 2020 at 04:01:18PM +0000, Steven Price wrote: >> On 17/11/2020 19:20, Marc Zyngier wrote: >>> On 2020-10-26 15:57, Steven Price wrote: >>>> diff --git a/arch/arm64/include/asm/sysreg.h >>>> b/arch/arm64/include/asm/sysreg.h >>>> index d52c1b3ce589..7727df0bc09d 100644 >>>> --- a/arch/arm64/include/asm/sysreg.h >>>> +++ b/arch/arm64/include/asm/sysreg.h >>>> @@ -565,7 +565,8 @@ >>>> �#define SCTLR_ELx_M��� (BIT(0)) >>>> >>>> �#define SCTLR_ELx_FLAGS��� (SCTLR_ELx_M� | SCTLR_ELx_A | SCTLR_ELx_C | \ >>>> -������������ SCTLR_ELx_SA | SCTLR_ELx_I | SCTLR_ELx_IESB) >>>> +������������ SCTLR_ELx_SA | SCTLR_ELx_I | SCTLR_ELx_IESB | \ >>>> +������������ SCTLR_ELx_ITFSB) >>>> >>>> �/* SCTLR_EL2 specific flags. */ >>>> �#define SCTLR_EL2_RES1��� ((BIT(4))� | (BIT(5))� | (BIT(11)) | >>>> (BIT(16)) | \ >>>> diff --git a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h >>>> b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h >>>> index 7a986030145f..a124ffa49ba3 100644 >>>> --- a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h >>>> +++ b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h >>>> @@ -18,6 +18,11 @@ >>>> �static inline void __sysreg_save_common_state(struct >>>> kvm_cpu_context *ctxt) >>>> �{ >>>> ���� ctxt_sys_reg(ctxt, MDSCR_EL1)��� = read_sysreg(mdscr_el1); >>>> +��� if (system_supports_mte()) { >>>> +������� ctxt_sys_reg(ctxt, RGSR_EL1)��� = read_sysreg_s(SYS_RGSR_EL1); >>>> +������� ctxt_sys_reg(ctxt, GCR_EL1)��� = read_sysreg_s(SYS_GCR_EL1); >>>> +������� ctxt_sys_reg(ctxt, TFSRE0_EL1)��� = >>>> read_sysreg_s(SYS_TFSRE0_EL1); >>> >>> As far as I can tell, HCR_EL2.ATA is still clear when running a guest. >>> So why, do we save/restore this state yet? >>> >>> Also, I wonder whether we should keep these in the C code. If one day >>> we enable MTE in the kernel, we will have to move them to the assembly >>> part, much like we do for PAuth. And I fear that "one day" is pretty >>> soon: >>> >>> https://lore.kernel.org/linux-arm-kernel/cover.1605046192.git.andreyknvl@google.com/ >> >> Good point. Although for MTE we do have the option of setting TCO in PSTATE >> so this could remain in C if we're not bothered about the 'gap' in KASAN >> coverage. I haven't yet got my head around how (or indeed if) that series >> handles guests. > > I think we should be fine with the currently proposed in-kernel MTE > support. However, setting GCR_EL1 can get in the way if stack tagging is > ever enabled (it breaks single image). The compiler uses GCR_EL1 to > generate different colours for variables on the stack and changing it in > the middle of a function may cause confusion. You'd have to set > PSTATE.TCO for the whole function, either from the caller or, if the > compiler gets smarter, some function attribute. > If the compiler might start playing with TCO then this could also be an issue for VMMs which will (at least with the current design) need to use TCO to safely access guest memory. Especially if we enforce PROT_MTE mappings for the VMM. Steve