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 D7C35C5AD7B for ; Mon, 10 Aug 2026 12:42:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References: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=d0gzdpj9zCfLl7pNf9nIx7V+XCOEuLZKa97f7OFeyLc=; b=QlW+uC48Vq7ygf TdUJYI63YBOffBCGLFSSz+R/jtMG5giu5iXh/DwpUdEuEzD+pu/Wx+Npy+CplMrqCTyOoK+iMNddi fWjoRWuIRyOr/jVMONSg/ZOjtoNJZBQYi8ldC6/SjY2XcDcVjUw1DzJArnnpWZfCbwTfQdSUp1rtW E6Qid16H+mFQfxhiIxUGLg8wy/Q4NwHA9160vI88CEcIdl+DRPiiGIbTVJBQjqitqMdaz0atNM8PH snxlcCfUiSpNszuIRptcU3Ho0Z4xi8yXKcqDOPSNRWGtSuWVEJNvtBX7JaNoCNpff/O0WL9GN/9Xg eFHzF8wTc3Z0u++7ioLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtPKj-0000000BneM-3qUJ; Mon, 10 Aug 2026 12:42:25 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtPKg-0000000Bndg-2M5l for linux-arm-kernel@lists.infradead.org; Mon, 10 Aug 2026 12:42:24 +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 5BC49143D; Mon, 10 Aug 2026 05:42:15 -0700 (PDT) Received: from [10.1.34.163] (e121487-lin.cambridge.arm.com [10.1.34.163]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0530A3F86F; Mon, 10 Aug 2026 05:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1786365739; bh=LfJqW5tpDOzFHBapUGs2MDgPQl1V/FtAeE1FZNBfIGU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ISeTa5nrufIkRolP9n8jeKaqRxnpZylF8jHYbBhn9QKqpGQyxayN7079KPL3QFBRR xv1T7sUzVLOIFjhKo6WhKLN2GUa5xsnPf9wUjM3ovXtRgKKuKTLhYgt7jog1pTQ58U mcH06Navhqr5PvcnAXX0PdEy+2K8oFCODp/aj2Ks= Message-ID: <2a97f777-d33a-4b3d-8c8c-6f6894f04c29@arm.com> Date: Mon, 10 Aug 2026 13:42:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC] arm64: entry: PSTATE_I_SET is leaking on pseudo NMI mode To: Will Deacon , Breno Leitao References: <20260807-arm64_fix-v1-1-d069ccf9d71b@debian.org> Content-Language: en-GB From: Vladimir Murzin In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260810_054222_767804_22DEDAEB X-CRM114-Status: GOOD ( 20.83 ) 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: , Cc: Mark Rutland , rmikey@meta.com, "Peter Zijlstra \(Intel\)" , Catalin Marinas , Jinjie Ruan , kernel-team@meta.com, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Will, On 8/10/26 12:43, Will Deacon wrote: > On Fri, Aug 07, 2026 at 09:29:12AM -0700, Breno Leitao wrote: >> On Fri, Aug 07, 2026 at 07:58:21AM -0700, Breno Leitao wrote: >>> Meanwhile, I will try to ftrace the writes to PMR and regs->pmr to get >>> a better grasp of the states machine we are in (probably on Monday). >> It seems LLM found a very easy to reproduce this: >> >> bash-5.1# dmesg >> >> bash-5.1# cd /sys/kernel/tracing >> echo 'r:pmr vfs_read bad=+0($retval):u64' >> kprobe_events >> echo 1 > events/kprobes/pmr/enable > Nice, that triggers straightforwardly in QEMU for me. The diff below > (which implements my suggestion from [1]) seems to fix the issue, but > it would be good to hear feedback from one of the Arm folks. > > Will > > [1] https://lore.kernel.org/all/anXgWRmcjwPKG7N5@willie-the-truck/ > > --->8 > > diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h > index 795b35128467..691ee5f86dbe 100644 > --- a/arch/arm64/include/asm/daifflags.h > +++ b/arch/arm64/include/asm/daifflags.h > @@ -132,7 +132,7 @@ static __always_inline void local_daif_inherit(struct pt_regs *regs) > trace_hardirqs_on(); > > if (system_uses_irq_prio_masking()) > - gic_write_pmr(regs->pmr); > + gic_write_pmr(regs->pmr & ~GIC_PRIO_PSR_I_SET); > > /* > * We can't use local_daif_restore(regs->pstate) here as > I have no strong opinion on the change, but I struggle to see how it fits into the big picture. Specifically, I have difficulty explaining this change in isolation. Everywhere else, we try to keep DAIF.I and GIC_PRIO_PSR_I_SET in sync, so it is not clear why we should allow them to go out of sync when inheriting the exception state from the previous context. At the same time, IIUC, the only reason we call local_irq_disable() (which also causes the states to become unsynchronized) in arm64_exit_to_kernel_mode() is for preemption path. So avoiding local_irq_disable() (and preemption) when we interrupted a non-preemptible context seems easier to follow. Alternatively, using local_daif_restore(DAIF_PROCCTX_NOIRQ) directly, if we believe it is OK to downgrade the inherited context, would achieve the same effect as local_irq_disable() while keeping DAIF and PMR in sync. Cheers Vladimir