From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.189 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793816929; b=kuhqAyLdAKHqRSzHqX/fpXOy+uBqz54hcMyFREyDLpFHqtONMwAr+d1+99EzYgQBcWQU 9F2843xy2cr2jXqQRps1sAEemB+RL3/q5R5lULLMfAEWpQq5q5ra6qIInm+Sfi2YSeGPU 2/QsMT1cAIjhrltqqljkodsA5PVi08wN+xPzYolawZdVcsOddiwJCooJj3QppjeWdpBm7 HJdqxZrGhB8BsQ8RG9vNHdyau9afIR85/YXaVtpf2r6JL6CDHWbO28J7H9VgGXtrUUYGw FQ6wrjyNpG6YM2TwGMf/leMN7H1pEf9oBRvS2DscGaBs0ZMIVsQVkPTV6IakNbJ/QZA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793816929; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:From:To:Cc:Subject:Date:Message-ID: X-Mailer:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding; bh=8AMRBsRaVVrjH9DufOp64hCzIFx64y5T91ZTRdXBHRQ=; b=1clCJ8+OvZEq0f74UzH0Hp95BQLixBXheZ05OD3xMhL6z+Kkc1HSLUIeRFEPYLqGBbeh DR+g8JEotksUg4r5yswLe5QJicUlWffOQhTI2X8n/csRO/GQJW9va7Ak1PuuFqmKTGX3x vdKmOq6wpnfToJaMH8XOxeO3Q7alInKeSVWNPgJ3BGMw59G9O6UV1AapsEgz/NpeeZ5i1 NjV9zzyPfuLpU0BdU2Vcj/7ndc47SQPRk8O9YWAl1ZyMq4aVfJUIGat/bVA+KVMGRxOyI BGZeZei66T4xoKKT8r0LqqmLE6Jt/8ILCamTUdodlpQ5L8xnsRtkYp5j337SSjCySHg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=q4HJidW4; arc=none smtp.remote-ip=95.215.58.189 Received: from mta1.migadu.com (out-189.mta1.migadu.com [95.215.58.189]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B458F606A8C9 for ; Wed, 4 Nov 2026 18:28:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org B458F606A8C9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=q4HJidW4 X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=mrdhsCyYkgJCthcE9mwZdhKXoi0YwuzvcjVgzOgRLv8=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793816925; v=1; x=1794421725; b=q4HJidW4HJrNqiFBIHcbsJipJ2hJej+ltF1PWamu0xne+Xed0E5vOFgrYxsiM7Mk/cLRO0Cd mQDxrG4cRPCdBoLfFjJAE1TL/NnuDUq0T1RrBM+K5gGsxUq+467GsBSKISbUQPXrkMyqMGtZkrm Hib/cFoyMAjhnXZA3vZKnplc= X-Envelope-To: linux-kernel@vger.kernel.org Received: by mta12.migadu.com with ESMTPS id fb19e5cc26c67389; Wed, 04 Nov 2026 18:28:45 +0000 X-Mizu-Trace-ID: fb19e5cc26c67389 X-Migadu-Flow: FLOW_OUT From: Usama Arif To: "Kiryl Shutsemau (Meta)" Cc: Usama Arif , Catalin Marinas , Will Deacon , Mark Rutland , James Morse , Marc Zyngier , Doug Anderson , Breno Leitao , Dawei Li , mrigendrachaubey , kernel-team@meta.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 1/2] arm64: sdei: Run the event handler on the kernel vectors Date: Wed, 4 Nov 2026 10:28:41 -0800 Message-ID: <20261104182842.3436759-1-usama.arif@linux.dev> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20261104180936.2981070-2-kas@kernel.org> References: X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, 4 Nov 2026 18:09:33 +0000 "Kiryl Shutsemau (Meta)" wrote: > With KPTI, VBAR_EL1 holds the trampoline vectors from the return to EL0 > until the next exception from EL0 maps the kernel and installs the > kernel vectors. The trampoline vectors only handle exceptions from EL0; > their current-EL half is zero-filled. > > An SDEI event is dispatched regardless of PSTATE.DAIF, so it lands there > whenever the CPU is in user space. The SDEI entry trampoline maps the > kernel but leaves VBAR_EL1 alone. An exception taken by the handler then > executes the zeros, takes an undefined instruction exception to the same > vector, and loops there forever. The event never completes and the CPU > is lost; RCU stall reports are the first sign of it. > > RAS notifications land in user space whenever a task consumes the > error, and NMI backtraces land wherever the CPU happens to be. The GHES > handler takes no exception on its own, but any exception in the handler > path does it: a WARN, a kprobe hit, or a fault fixed up by a _nofault() > accessor. > > Install the kernel vectors in do_sdei_event() when VBAR_EL1 holds the > trampoline vectors, and restore it before returning to firmware, > including when the handler fails. The IRQ-like resume into user space > keeps using the interrupted value, as it must go through the trampoline > to map the kernel. > > Fixes: 79e9aa59dc29 ("arm64: sdei: Add trampoline code for remapping the kernel") > Cc: stable@vger.kernel.org > Signed-off-by: Kiryl Shutsemau (Meta) > --- > arch/arm64/kernel/sdei.c | 22 ++++++++++++++++++++-- > 1 file changed, 20 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/sdei.c b/arch/arm64/kernel/sdei.c > index 778f2a1faac8..9fa2a3aeed48 100644 > --- a/arch/arm64/kernel/sdei.c > +++ b/arch/arm64/kernel/sdei.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > #include > > unsigned long sdei_exit_mode; > @@ -214,6 +215,20 @@ unsigned long __kprobes do_sdei_event(struct pt_regs *regs, > if (arm64_kernel_unmapped_at_el0()) > clobbered_registers++; > > + /* > + * With KPTI, VBAR_EL1 holds the trampoline vectors from the return to > + * EL0 until the next exception from EL0 maps the kernel. They only > + * handle exceptions from EL0: an exception taken by the handler would > + * run their empty current-EL half and never come back. Run the handler > + * on the kernel vectors. The IRQ-like resume below keeps using the > + * interrupted VBAR, so it still goes through the trampoline. > + */ > + if (arm64_kernel_unmapped_at_el0() && > + vbar == (unsigned long)this_cpu_read(this_cpu_vector)) { > + write_sysreg((unsigned long)vectors, vbar_el1); > + isb(); > + } > + Does this cover the whole path that can take an exception? The swap is done inside do_sdei_event(), but __sdei_handler() calls irqentry_nmi_enter() before it and irqentry_nmi_exit() after it, and both of those still run with the trampoline vectors in VBAR_EL1 when the event interrupted user space. Both can take an exception. ct_nmi_enter() opens with WARN_ON_ONCE(ct_nmi_nesting() < 0), and ct_nmi_exit() has WARN_ON_ONCE(ct_nmi_nesting() <= 0) and WARN_ON_ONCE(!rcu_is_watching_curr_cpu()). A WARN is a BRK, so either would run the zero filled current-EL half and lose the CPU in the way the commit message describes. Would doing the swap in __sdei_handler(), around the whole NMI entry and exit pair, close that window? > /* Retrieve the missing registers values */ > for (i = 0; i < clobbered_registers; i++) { > /* from within the handler, this call always succeeds */ > @@ -221,8 +236,6 @@ unsigned long __kprobes do_sdei_event(struct pt_regs *regs, > } > > err = sdei_event_handler(regs, arg); > - if (err) > - return SDEI_EV_FAILED; > > if (elr != read_sysreg(elr_el1)) { > /* > @@ -233,6 +246,11 @@ unsigned long __kprobes do_sdei_event(struct pt_regs *regs, > pr_warn("unsafe: exception during handler\n"); > } > > + write_sysreg(vbar, vbar_el1); > + > + if (err) > + return SDEI_EV_FAILED; > + > mode = regs->pstate & (PSR_MODE32_BIT | PSR_MODE_MASK); > > /* > -- > 2.54.0 > >