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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EA399C48BC4 for ; Fri, 23 Feb 2024 07:29:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=YnTyV+aCu8kUjxsdAWy7sG8xj3Hzl6WAGm9NvIZF9XY=; b=JsKfm98jGTW6lN MaUv22Bc8P7iOHAIoZUoDFvePbXFVNP02qFC1LOgELxaxmFCFHqeFVbP8tdrYhYAI4sy4fymXLLql YyyqquKs+y2WlMAblfdSBKwCFMF8tsL2oHh/GnYkGYDijlAZPUeOkLVOCqt0+DNcLSowdCwZjfjfn IFvXZp2BRl0J/2BL2e9R0zoabqiWK5Lp+BiSKXc8T7nCFZaNSM/COn1l/Yf1KD4ZYm70U2KEtxg3j N842VOhukGKW/B6b1IA3N3Ja+8JQMfc0gv7TS51EAkPfBpXbl7XepwMy3dmgK5J5KZIN6i+FlrJ3m G2HfnoAs9oO4ndfban8w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rdPzi-00000008Ia6-2h6d; Fri, 23 Feb 2024 07:29:18 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rdPzQ-00000008IVV-26ZQ for linux-arm-kernel@lists.infradead.org; Fri, 23 Feb 2024 07:29:09 +0000 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 E77961650; Thu, 22 Feb 2024 23:29:34 -0800 (PST) Received: from [10.163.46.223] (unknown [10.163.46.223]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F220A3F73F; Thu, 22 Feb 2024 23:28:50 -0800 (PST) Message-ID: Date: Fri, 23 Feb 2024 12:58:48 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V16 2/8] KVM: arm64: Prevent guest accesses into BRBE system registers/instructions Content-Language: en-US To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, Mark Brown , James Clark , Rob Herring , Marc Zyngier , Suzuki Poulose , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , linux-perf-users@vger.kernel.org, Oliver Upton , James Morse , kvmarm@lists.linux.dev References: <20240125094119.2542332-1-anshuman.khandual@arm.com> <20240125094119.2542332-3-anshuman.khandual@arm.com> From: Anshuman Khandual In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240222_232906_817751_24D05D1D X-CRM114-Status: GOOD ( 23.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2/21/24 19:31, Mark Rutland wrote: > On Thu, Jan 25, 2024 at 03:11:13PM +0530, Anshuman Khandual wrote: >> Currently BRBE feature is not supported in a guest environment. This hides >> BRBE feature availability via masking ID_AA64DFR0_EL1.BRBE field. > > Does that means that a guest can currently see BRBE advertised in the > ID_AA64DFR0_EL1.BRB field, or is that hidden by the regular cpufeature code > today? IIRC it is hidden, but will have to double check. When experimenting for BRBE guest support enablement earlier, following changes were need for the feature to be visible in ID_AA64DFR0_EL1. diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 646591c67e7a..f258568535a8 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -445,6 +445,7 @@ static const struct arm64_ftr_bits ftr_id_mmfr0[] = { }; static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = { + S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_EL1_BRBE_SHIFT, 4, ID_AA64DFR0_EL1_BRBE_IMP), S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_EL1_DoubleLock_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64DFR0_EL1_PMSVer_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_EL1_CTX_CMPs_SHIFT, 4, 0), Should we add the following entry - explicitly hiding BRBE from the guest as a prerequisite patch ? S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_EL1_BRBE_SHIFT, 4, ID_AA64DFR0_EL1_BRBE_NI) > >> This also blocks guest accesses into BRBE system registers and instructions >> as if the underlying hardware never implemented FEAT_BRBE feature. >> >> Cc: Marc Zyngier >> Cc: Oliver Upton >> Cc: James Morse >> Cc: Suzuki K Poulose >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: kvmarm@lists.linux.dev >> Cc: linux-arm-kernel@lists.infradead.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Anshuman Khandual >> --- >> Changes in V16: >> >> - Added BRB_INF_SRC_TGT_EL1 macro for corresponding BRB_[INF|SRC|TGT] expansion >> >> arch/arm64/kvm/sys_regs.c | 56 +++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 56 insertions(+) >> >> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c >> index 30253bd19917..6a06dc2f0c06 100644 >> --- a/arch/arm64/kvm/sys_regs.c >> +++ b/arch/arm64/kvm/sys_regs.c >> @@ -1304,6 +1304,11 @@ static int set_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r, >> return 0; >> } >> >> +#define BRB_INF_SRC_TGT_EL1(n) \ >> + { SYS_DESC(SYS_BRBINF##n##_EL1), undef_access }, \ >> + { SYS_DESC(SYS_BRBSRC##n##_EL1), undef_access }, \ >> + { SYS_DESC(SYS_BRBTGT##n##_EL1), undef_access } \ > > With the changes suggested on the previous patch, this would need to change to be: > > #define BRB_INF_SRC_TGT_EL1(n) \ > { SYS_DESC(SYS_BRBINF_EL1(n)), undef_access }, \ > { SYS_DESC(SYS_BRBSRC_EL1(n)), undef_access }, \ > { SYS_DESC(SYS_BRBTGT_EL1(n)), undef_access } \ Sure, already folded back in these above changes. > > > ... which would also be easier for backporting (if necessary), since those > definitions have existed for a while. > > Otherwise (modulo Suzuki's comment about rebasing), this looks good to me. Okay. > > Mark. > >> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */ >> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \ >> { SYS_DESC(SYS_DBGBVRn_EL1(n)), \ >> @@ -1707,6 +1712,9 @@ static u64 read_sanitised_id_aa64dfr0_el1(struct kvm_vcpu *vcpu, >> /* Hide SPE from guests */ >> val &= ~ID_AA64DFR0_EL1_PMSVer_MASK; >> >> + /* Hide BRBE from guests */ >> + val &= ~ID_AA64DFR0_EL1_BRBE_MASK; >> + >> return val; >> } >> >> @@ -2195,6 +2203,8 @@ static const struct sys_reg_desc sys_reg_descs[] = { >> { SYS_DESC(SYS_DC_CISW), access_dcsw }, >> { SYS_DESC(SYS_DC_CIGSW), access_dcgsw }, >> { SYS_DESC(SYS_DC_CIGDSW), access_dcgsw }, >> + { SYS_DESC(OP_BRB_IALL), undef_access }, >> + { SYS_DESC(OP_BRB_INJ), undef_access }, >> >> DBG_BCR_BVR_WCR_WVR_EL1(0), >> DBG_BCR_BVR_WCR_WVR_EL1(1), >> @@ -2225,6 +2235,52 @@ static const struct sys_reg_desc sys_reg_descs[] = { >> { SYS_DESC(SYS_DBGCLAIMCLR_EL1), trap_raz_wi }, >> { SYS_DESC(SYS_DBGAUTHSTATUS_EL1), trap_dbgauthstatus_el1 }, >> >> + /* >> + * BRBE branch record sysreg address space is interleaved between >> + * corresponding BRBINF_EL1, BRBSRC_EL1, and BRBTGT_EL1. >> + */ >> + BRB_INF_SRC_TGT_EL1(0), >> + BRB_INF_SRC_TGT_EL1(16), >> + BRB_INF_SRC_TGT_EL1(1), >> + BRB_INF_SRC_TGT_EL1(17), >> + BRB_INF_SRC_TGT_EL1(2), >> + BRB_INF_SRC_TGT_EL1(18), >> + BRB_INF_SRC_TGT_EL1(3), >> + BRB_INF_SRC_TGT_EL1(19), >> + BRB_INF_SRC_TGT_EL1(4), >> + BRB_INF_SRC_TGT_EL1(20), >> + BRB_INF_SRC_TGT_EL1(5), >> + BRB_INF_SRC_TGT_EL1(21), >> + BRB_INF_SRC_TGT_EL1(6), >> + BRB_INF_SRC_TGT_EL1(22), >> + BRB_INF_SRC_TGT_EL1(7), >> + BRB_INF_SRC_TGT_EL1(23), >> + BRB_INF_SRC_TGT_EL1(8), >> + BRB_INF_SRC_TGT_EL1(24), >> + BRB_INF_SRC_TGT_EL1(9), >> + BRB_INF_SRC_TGT_EL1(25), >> + BRB_INF_SRC_TGT_EL1(10), >> + BRB_INF_SRC_TGT_EL1(26), >> + BRB_INF_SRC_TGT_EL1(11), >> + BRB_INF_SRC_TGT_EL1(27), >> + BRB_INF_SRC_TGT_EL1(12), >> + BRB_INF_SRC_TGT_EL1(28), >> + BRB_INF_SRC_TGT_EL1(13), >> + BRB_INF_SRC_TGT_EL1(29), >> + BRB_INF_SRC_TGT_EL1(14), >> + BRB_INF_SRC_TGT_EL1(30), >> + BRB_INF_SRC_TGT_EL1(15), >> + BRB_INF_SRC_TGT_EL1(31), >> + >> + /* Remaining BRBE sysreg addresses space */ >> + { SYS_DESC(SYS_BRBCR_EL1), undef_access }, >> + { SYS_DESC(SYS_BRBFCR_EL1), undef_access }, >> + { SYS_DESC(SYS_BRBTS_EL1), undef_access }, >> + { SYS_DESC(SYS_BRBINFINJ_EL1), undef_access }, >> + { SYS_DESC(SYS_BRBSRCINJ_EL1), undef_access }, >> + { SYS_DESC(SYS_BRBTGTINJ_EL1), undef_access }, >> + { SYS_DESC(SYS_BRBIDR0_EL1), undef_access }, >> + >> { SYS_DESC(SYS_MDCCSR_EL0), trap_raz_wi }, >> { SYS_DESC(SYS_DBGDTR_EL0), trap_raz_wi }, >> // DBGDTR[TR]X_EL0 share the same encoding >> -- >> 2.25.1 >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel