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

[Catalin Marinas <catalin.marinas@arm.com>]

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.

-- 
Catalin