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 561FFCFD376 for ; Fri, 28 Nov 2025 08:43:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YVQ+SU+WCgIS+NsWm0ZfKJfU/F3iqzvlc8nCLWcVgKo=; b=CVHXF4CWkLvbn8xS/J6xd49XhZ qKL6CaGomrkETAteemlAscTR/D2/0Oax2l5Gsk5Cq+3S31+OELSFw9F8Aq5uqtnulLbGiOWYLC5M6 mtrXbnMLnBvpgB5WK7esfbfuSdvXmW7fRS2CqmxTuupY8LZUIxQNlLVTXj66aZjwxFqUlWU4mYs3O hfO50JbWbGCbry1PSYzThLWosSbt7ZMWhg3SguZy5fIZ4lEc7/slVKWGa5WElNEwwYJWLef99m81c OizrVQEBuEi/abxHaRKwWUCD9WnqoeM0pE9G717hAl/pUuXmDPiV2QogVTjLlgYQFb0rTWkfNWCqW tc+RMdRw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vOu4S-00000000Bae-1pxQ; Fri, 28 Nov 2025 08:43:16 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vOu4R-00000000BaV-0g4S for linux-arm-kernel@lists.infradead.org; Fri, 28 Nov 2025 08:43:15 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 9693360251; Fri, 28 Nov 2025 08:43:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45F97C4CEF1; Fri, 28 Nov 2025 08:43:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764319393; bh=HHFxMq+EVjNrn/S3W2wE1fNTsZjWCLaDDlrITqoPVC8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=c4ksTJbXTPIECgzbRJrIWfptyv6HQes3skMGZcQbdnEnIDlRTxLUWhuv1PRffCGea DKcnphE5H1c/j+gh9N1gEoPvGwBvaOu7iBmen46oH9PgdRCM/Q3lGkcr4SG9heQmpL LFGb9rZOEBcx/gZEnb5egbylrOsFLUF0xMdzHTkhNIJfbUcWZgizYcuzWHp47MC0+F A9BhuaV6hn4+DuYbzwD6uKhSyFVN+U0YzwHXlaVyL+vCPobwllknPSaRxa1bahKQqi eFWxEXUykUVNZdvg0CdRNHOzQ/fL/XPRkiMMTp3wo8NUbIiG+bHfeu6+YeFXux955C s7I6l88BpIPjQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vOu4M-0000000903K-1FOy; Fri, 28 Nov 2025 08:43:10 +0000 Date: Fri, 28 Nov 2025 08:43:09 +0000 Message-ID: <86wm3apmxu.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org Subject: Re: [PATCH v1 4/5] arm64: Inject UNDEF when accessing MTE sysregs with MTE disabled In-Reply-To: References: <20251127122210.4111702-1-tabba@google.com> <20251127122210.4111702-5-tabba@google.com> <86345zr24c.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: tabba@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 27 Nov 2025 14:41:24 +0000, Fuad Tabba wrote: > > Hi Marc, > > On Thu, 27 Nov 2025 at 14:17, Marc Zyngier wrote: > > > > On Thu, 27 Nov 2025 12:22:09 +0000, > > Fuad Tabba wrote: > > > > > > When MTE hardware is present but disabled via software (arm64.nomte or > > > CONFIG_ARM64_MTE=n), HCR_EL2.ATA is cleared to prevent use of MTE > > > instructions. However, this alone doesn't fully emulate hardware that > > > lacks MTE support. > > > > > > With HCR_EL2.ATA cleared, accesses to certain MTE system registers trap > > > to EL2 with exception class ESR_ELx_EC_SYS64. To faithfully emulate > > > hardware without MTE (where such accesses would cause an Undefined > > > Instruction exception), inject UNDEF into the host. > > > > > > Signed-off-by: Fuad Tabba > > > --- > > > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 44 ++++++++++++++++++++++++++++++ > > > 1 file changed, 44 insertions(+) > > > > > > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c > > > index 29430c031095..f542e4c17156 100644 > > > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c > > > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c > > > @@ -686,6 +686,46 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt) > > > kvm_skip_host_instr(); > > > } > > > > > > +static void inject_undef64(void) > > > +{ > > > + unsigned long sctlr, vbar, old, new; > > > + u64 offset, esr; > > > + > > > + vbar = read_sysreg_el1(SYS_VBAR); > > > + sctlr = read_sysreg_el1(SYS_SCTLR); > > > + old = read_sysreg_el2(SYS_SPSR); > > > + new = get_except64_cpsr(old, system_supports_mte(), sctlr, PSR_MODE_EL1h); > > > + offset = get_except64_offset(old, PSR_MODE_EL1h, except_type_sync); > > > + esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT) | ESR_ELx_IL; > > > + > > > + write_sysreg_el1(esr, SYS_ESR); > > > + write_sysreg_el1(read_sysreg_el2(SYS_ELR), SYS_ELR); > > > + write_sysreg_el1(old, SYS_SPSR); > > > + write_sysreg_el2(vbar + offset, SYS_ELR); > > > + write_sysreg_el2(new, SYS_SPSR); > > > +} > > > + > > > +static bool handle_host_mte(u64 esr) > > > +{ > > > + /* If we're here for any reason other than MTE, then it's a bug. */ > > > + > > > + if (read_sysreg(HCR_EL2) & HCR_ATA) > > > + return false; > > > + > > > + switch (esr_sys64_to_sysreg(esr)) { > > > + case SYS_RGSR_EL1: > > > + case SYS_GCR_EL1: > > > + case SYS_TFSR_EL1: > > > + case SYS_TFSRE0_EL1: > > > > How about other things, such as DC GVA? Don't you need to trap and > > UNDEF it (which has the side effect of also trapping DC ZVA)? > > > > Same question for all the DC {C,I,CI}GVA{C,P} instructions. > > As far as I could tell, none of these are trapped by ATA. The spec > says that in the absence of MTE, their behavior is undefined --- which > is the same for the ones I'm actually handling here... > > The reasons I've only handled these is that, when booting a system > with a misadvertised MTE, the kernel accesses these registers, and > injecting an UNDEF resulted in a nicer failure mode. But it all comes down to *why* is MTE disabled. Is it because the user cannot be arsed with MTE's abysmal^Wstellar performance? Or because this is a memory corruption vector on a misconfigured platform? > What do you suggest, drop this patch (and the one before it), since > trying to access MTE is UNDEF, and the kernel that does it is just > shooting itself in the foot (no security implications)? Or edit the > commit message to make it clear that this is best effort, based on > what ATA traps? No, what I am simply pointing out that that there is more to MTE than what gets trapped by ATA, and my hunch is that when MTE is disabled on machine that actually has it, it is because something is deeply broken with tag management (I have one such machine). So depending which side of the problem you're on, this could be either perfectly valid, or just missing the point. Thanks, M. -- Without deviation from the norm, progress is not possible.