Re: [PATCH v18] arm64: mm: Handle Granule Protection Faults (GPFs)

[Will Deacon <will@kernel.org>]

On Wed, Sep 23, 2026 at 12:06:15PM +0100, Catalin Marinas wrote:
> On Tue, Sep 22, 2026 at 06:15:34PM +0100, Will Deacon wrote:
> > On Sun, Sep 13, 2026 at 08:04:58AM +0100, Suzuki K Poulose wrote:
> > > From: Steven Price <steven.price@arm.com>
> > > 
> > > If the host attempts to access granules that have been delegated for use
> > > in a realm these accesses will be caught and will trigger a Granule
> > > Protection Fault (GPF).
> > > 
> > > A fault during a page walk signals a bug in the kernel and is handled by
> > > oopsing the kernel. A non-page walk fault could be caused by user space
> > > having access to a page which has been delegated to the kernel and will
> > > trigger a SIGBUS to allow debugging why user space is trying to access a
> > > delegated page.
> > > 
> > > There is work in progress to unmap the guest_memfd backed private pages from the
> > > linear map. Until we get that support, we could get spurious GPFs from within
> > > the kernel, e.g., load_unaligned_zeropad(). So, try to fix them up for now.
> > > 
> > > Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > > Reviewed-by: Gavin Shan <gshan@redhat.com>
> > > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > > Signed-off-by: Steven Price <steven.price@arm.com>
> > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > > ---
> > > Changes since v17:
> > >  * Pass untagged address to die_kernel_fault() - Sashiko
> > >  * Explicitly check !user_mode() for fixups - Catalin
> > >  * Switch to BUS_OBJERR for si_code from SI_KERNEL - Catalin
> > >  * Clarify the commit description about the upcoming work on
> > >    unmapping guest_memfd backed pages from linear map
> > > Changes since v16:
> > >  * Update the commit description to indicate why we try to fixup GPFs
> > > Changes since v10:
> > >  * Don't call arm64_notify_die() in do_gpf() but simply return 1.
> > > Changes since v2:
> > >  * Include missing "Granule Protection Fault at level -1"
> > > ---
> > >  arch/arm64/mm/fault.c | 30 ++++++++++++++++++++++++------
> > >  1 file changed, 24 insertions(+), 6 deletions(-)
> > 
> > I still don't think we should do this, given that the plan is to unmap
> > the memory from the linear map. If this thing fires, it's a kernel bug
> > and it should be fatal.
> 
> If the linear unmapping gets merged first, I agree, no need to handle
> these faults. I haven't followed that series, so no idea where it is at.
> 
> However, I'd still keep part of this patch - the reporting and panic but
> without the actual exception table recovery. There's some value in
> killing user-space and WARN (or pr_ratelimited) without a full panic, it
> helps with debugging. That's what do_bad() via arm64_notify_die() gives
> us currently anyway.
> 
> So maybe we can keep it to just:
> 
> static int do_gpf(unsigned long far, unsigned long esr, struct pt_regs *regs)
> {
> 	if (user_mode(regs)) {
> 		pr_alert_ratelimited("%s[%d]: granule protection fault at 0x%016lx\n",
> 				current->comm, task_pid_nr(current),
> 				untagged_addr(far));
> 		mem_abort_decode(esr);
> 	}
> 
> 	return 1;
> }
> 
> and we get the SIGBUS or panic via do_mem_abort(). No recovery for
> uaccess though, we get the same kernel panic.

But how can this ever occur in user mode? I'm fine with making that part
unconditional.

Will