From patchwork Tue Feb 13 10:27:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoffer Dall X-Patchwork-Id: 10215837 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 843876055C for ; Tue, 13 Feb 2018 10:28:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7C9402884E for ; Tue, 13 Feb 2018 10:28:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 712AF28DD5; Tue, 13 Feb 2018 10:28:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id AE2772884E for ; Tue, 13 Feb 2018 10:28:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fr5tBKeG2BVK7QOmd/Q7qk7oPLYCn4NxewEDgzRGRF8=; b=Y0iCs4Tk7qYuC5 idQMLXiHxfLDJVg3ksCWyYFvQCo8WPlMcIvdrskUaqScpXWUNkaqbBftx+p+QiRijznJAc60BIzyS tV6nv/Wg/luLiDysaQcy1qN10PEGN5XZEVbmNTXwdUrlz9ie1OfL3lsxlRUd87gwLAlQ8YrU/ykyP 9cLg+GK3+Zbb6ZUFEmKvA6ZZ/sUlYH53LCT/B9tHIY6JL7zlE6+ZPP/fcdw6x4AP9K0Aw+bDTNilF xWp/l6u8Z1Ae7as/kwWckoWLD+g/B1xutPs0dlXQO9FN2MkPl4Y1eDlMlsSEj7MsFT53vRpZlEoPQ 5Qy1pDrU9eaiYzAGWFbA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.89 #1 (Red Hat Linux)) id 1elXoo-0005tW-WF; Tue, 13 Feb 2018 10:28:11 +0000 Received: from mail-wm0-x243.google.com ([2a00:1450:400c:c09::243]) by bombadil.infradead.org with esmtps (Exim 4.89 #1 (Red Hat Linux)) id 1elXoa-0005g4-JY for linux-arm-kernel@lists.infradead.org; Tue, 13 Feb 2018 10:28:06 +0000 Received: by mail-wm0-x243.google.com with SMTP id 141so15033761wme.3 for ; Tue, 13 Feb 2018 02:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=rfiuY6xYVz084C08enwVefvMJHm6j4UlWxXlQoLlg88=; b=RQG/JFolJ70RSJuUAohNNS/jVeAUBA3Jz2IOCosEW64EZEbQ9ptnCbn0iVJxzIqgzx /g0+439SaZhWxR+d6dr8tpaemeqcIpcFN/U7+3nJWk23oF0XOpHU9rGh3iKR58QKofF6 ZF9iUJSmUiAGpiRo1jiFvstpMLVIy8datl8XQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rfiuY6xYVz084C08enwVefvMJHm6j4UlWxXlQoLlg88=; b=FBa6G4zVLXe5JV0kfIo03f+Hqo4B30xHCLoDHuHeGTwMEVgvjQZuzWgettdLnDwnP5 6VALkEWbThZaxIC9+6NK3PoFBnun5W1/ZoUTEHyucbW9wJ0DoqCuK7OavQc4WgP4vRw8 O3q0IuomyhCiX4aFNrc/Hd+ap6jrxqBjjtCo3RH3RQ+a3QKpERIqAEnLMTjOGJY4aXwP AhF9MudoYo1PlYhF1s/zoahZvL36l6V08PZFR0fjAwSuO/4S+3Vst1hdsJ4MgXUVXTXL nNSqUtqzE7GzBQLMGQpfNbLkkLUlOlpN7WIGFqJ3Qnqrq5z3fAfeGy3d6iYsTwnSR3EA aO3w== X-Gm-Message-State: APf1xPAoXq4sQAZXCRnZGs2debu3JKf4S3QcX5dd8rGvh/kegJd/Qjm0 G79A3+4EQrNuD9Zia1Byz6w8iw== X-Google-Smtp-Source: AH8x2269o1VvGKIz8m3MKougeFQJhBloU3QOO8HZqqdz/+PNlJ7yT72LmKecjlisEW+f2hM+kVBfbw== X-Received: by 10.80.179.146 with SMTP id s18mr1544439edd.190.1518517664171; Tue, 13 Feb 2018 02:27:44 -0800 (PST) Received: from localhost (x50d2404e.cust.hiper.dk. [80.210.64.78]) by smtp.gmail.com with ESMTPSA id u4sm6184294edc.91.2018.02.13.02.27.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 02:27:43 -0800 (PST) Date: Tue, 13 Feb 2018 11:27:42 +0100 From: Christoffer Dall To: Mark Rutland Subject: Re: [PATCH] arm64/kvm: Prohibit guest LOR accesses Message-ID: <20180213102742.GG23189@cbox> References: <20180212111424.39248-1-mark.rutland@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180212111424.39248-1-mark.rutland@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180213_022756_705501_22028F56 X-CRM114-Status: GOOD ( 26.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , Catalin Marinas , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Mark, On Mon, Feb 12, 2018 at 11:14:24AM +0000, Mark Rutland wrote: > We don't currently limit guest accesses to the LOR registers, which we > neither virtualize nor context-switch. As such, guests are provided with > unusable information/controls, and are not isolated from each other (or > the host). > > To prevent these issues, we can trap register accesses and present the > illusion that no LORegions are implemented. Shouldn't we then also hide this from the ID register similar to what we do for SVE at the moment, using something like this (untested): > Per ARM DDI 0487B.a, in this > case all fields in LORID_EL1 will contain zero, and: > > * LORC_EL1 is RW, RES0 (D7.2.65 "Configurations" & "Accessibility") > * LOREA_EL1 is RW, RES0 (D7.2.66 "Configurations" & "Accessibility") > * LORN_EL1 is RW, RES0 (D7.2.68 "Configurations" & "Accessibility") > * LORSA_EL1 is RW, RES0 (D7.2.69 "Configurations" & "Accessibility") > > Note that LORID_EL1 itself is RO per D7.2.67. > > As noted in D7.2.67, when no LORegions are implemented, LoadLOAcquire > and StoreLORelease must behave as LoadAcquire and StoreRelease > respectively. We can ensure this by clearing LORC_EL1.EN when a CPU's > EL2 is first initialized, as the host kernel will not modify this. > > Signed-off-by: Mark Rutland > Reviewed-by: Vladimir Murzin > Cc: Catalin Marinas > Cc: Christoffer Dall > Cc: Marc Zyngier > Cc: Will Deacon > Cc: kvmarm@lists.cs.columbia.edu > --- > arch/arm64/include/asm/kvm_arm.h | 4 +++- > arch/arm64/include/asm/sysreg.h | 6 ++++++ > arch/arm64/kernel/head.S | 7 +++++++ > arch/arm64/kvm/sys_regs.c | 17 +++++++++++++++++ > 4 files changed, 33 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h > index b0c84171e6a3..1b438c334463 100644 > --- a/arch/arm64/include/asm/kvm_arm.h > +++ b/arch/arm64/include/asm/kvm_arm.h > @@ -25,6 +25,7 @@ > /* Hyp Configuration Register (HCR) bits */ > #define HCR_TEA (UL(1) << 37) > #define HCR_TERR (UL(1) << 36) > +#define HCR_TLOR (UL(1) << 35) > #define HCR_E2H (UL(1) << 34) > #define HCR_ID (UL(1) << 33) > #define HCR_CD (UL(1) << 32) > @@ -64,6 +65,7 @@ > > /* > * The bits we set in HCR: > + * TLOR: Trap LORegion register accesses > * RW: 64bit by default, can be overridden for 32bit VMs > * TAC: Trap ACTLR > * TSC: Trap SMC > @@ -81,7 +83,7 @@ > */ > #define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWE | HCR_TWI | HCR_VM | \ > HCR_TVM | HCR_BSU_IS | HCR_FB | HCR_TAC | \ > - HCR_AMO | HCR_SWIO | HCR_TIDCP | HCR_RW) > + HCR_AMO | HCR_SWIO | HCR_TIDCP | HCR_RW | HCR_TLOR) > #define HCR_VIRT_EXCP_MASK (HCR_VSE | HCR_VI | HCR_VF) > #define HCR_INT_OVERRIDE (HCR_FMO | HCR_IMO) > #define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H) > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h > index 0e1960c59197..69a99856461c 100644 > --- a/arch/arm64/include/asm/sysreg.h > +++ b/arch/arm64/include/asm/sysreg.h > @@ -288,6 +288,12 @@ > #define SYS_MAIR_EL1 sys_reg(3, 0, 10, 2, 0) > #define SYS_AMAIR_EL1 sys_reg(3, 0, 10, 3, 0) > > +#define SYS_LORSA_EL1 sys_reg(3, 0, 10, 4, 0) > +#define SYS_LOREA_EL1 sys_reg(3, 0, 10, 4, 1) > +#define SYS_LORN_EL1 sys_reg(3, 0, 10, 4, 2) > +#define SYS_LORC_EL1 sys_reg(3, 0, 10, 4, 3) > +#define SYS_LORID_EL1 sys_reg(3, 0, 10, 4, 7) > + > #define SYS_VBAR_EL1 sys_reg(3, 0, 12, 0, 0) > #define SYS_DISR_EL1 sys_reg(3, 0, 12, 1, 1) > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S > index 2b6b8b24e5ab..b0853069702f 100644 > --- a/arch/arm64/kernel/head.S > +++ b/arch/arm64/kernel/head.S > @@ -577,6 +577,13 @@ set_hcr: > 7: > msr mdcr_el2, x3 // Configure debug traps > > + /* LORegions */ > + mrs x1, id_aa64mmfr1_el1 > + ubfx x0, x1, #ID_AA64MMFR1_LOR_SHIFT, 4 > + cbz x0, 1f > + msr_s SYS_LORC_EL1, xzr > +1: > + > /* Stage-2 translation */ > msr vttbr_el2, xzr > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 50a43c7b97ca..67b10b7a07bf 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -175,6 +175,17 @@ static bool trap_raz_wi(struct kvm_vcpu *vcpu, > return read_zero(vcpu, p); > } > > +static bool trap_raz_ro(struct kvm_vcpu *vcpu, > + struct sys_reg_params *p, > + const struct sys_reg_desc *r) > +{ > + if (!p->is_write) > + return read_zero(vcpu, p); > + > + kvm_inject_undefined(vcpu); > + return false; > +} > + I'm a little unclear if this is stricly the right thing to do. I can't seem to find anything specific about writes to this register (which has some text about RW fields but only specifies it can be *read* with an MRS instruction), so it seems to me that this should either be trap_raz_wi(), or call write_to_read_only() if we expect a write to undef at EL1 rather than trap to EL2. On the other hand, if the architecture is unclear, then we're at least enforcing one interpretation here I suppose. > static bool trap_oslsr_el1(struct kvm_vcpu *vcpu, > struct sys_reg_params *p, > const struct sys_reg_desc *r) > @@ -1178,6 +1189,12 @@ static const struct sys_reg_desc sys_reg_descs[] = { > { SYS_DESC(SYS_MAIR_EL1), access_vm_reg, reset_unknown, MAIR_EL1 }, > { SYS_DESC(SYS_AMAIR_EL1), access_vm_reg, reset_amair_el1, AMAIR_EL1 }, > > + { SYS_DESC(SYS_LORSA_EL1), trap_raz_wi }, > + { SYS_DESC(SYS_LOREA_EL1), trap_raz_wi }, > + { SYS_DESC(SYS_LORN_EL1), trap_raz_wi }, > + { SYS_DESC(SYS_LORC_EL1), trap_raz_wi }, > + { SYS_DESC(SYS_LORID_EL1), trap_raz_ro }, > + > { SYS_DESC(SYS_VBAR_EL1), NULL, reset_val, VBAR_EL1, 0 }, > { SYS_DESC(SYS_DISR_EL1), NULL, reset_val, DISR_EL1, 0 }, > > -- > 2.11.0 > Thanks, -Christoffer diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index a828a209716f..b7ee414aee67 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1064,6 +1064,12 @@ static u64 read_id_reg(struct sys_reg_desc const *r, bool raz) task_pid_nr(current)); val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT); + } else if (id == SYS_ID_AA64MMFR1_EL) { + if (val & (0xfUL << ID_AA64MMFR1_LOR_SHIFT)) + pr_err_once("kvm [%i]: LORegions unsupported for guests, suppressing\n", + task_pid_nr(current)); + + val &= ~(0xfUL << ID_AA64MMFR1_LOR_SHIFT); } return val;