[PATCH v16 07/45] arm64: mm: Handle Granule Protection Faults (GPFs)

[Pavan Kondeti]

On Tue, Aug 11, 2026 at 04:11:13PM +0100, Suzuki K Poulose wrote:
> On 11/08/2026 15:44, Catalin Marinas wrote:
> > On Mon, Aug 03, 2026 at 02:43:23PM +0100, Steven Price wrote:
> > > 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.
> > > 
> > > Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
> > > Reviewed-by: Gavin Shan <gshan at redhat.com>
> > > Signed-off-by: Steven Price <steven.price at arm.com>
> > > ---
> > > 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 | 28 ++++++++++++++++++++++------
> > >   1 file changed, 22 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > > index 85e23388f9bb..ea3ae0ca7dba 100644
> > > --- a/arch/arm64/mm/fault.c
> > > +++ b/arch/arm64/mm/fault.c
> > > @@ -909,6 +909,22 @@ static int do_tag_check_fault(unsigned long far, unsigned long esr,
> > >   	return 0;
> > >   }
> > > +static int do_gpf_ptw(unsigned long far, unsigned long esr, struct pt_regs *regs)
> > > +{
> > > +	const struct fault_info *inf = esr_to_fault_info(esr);
> > > +
> > > +	die_kernel_fault(inf->name, far, esr, regs);
> > > +	return 0;
> > > +}
> > > +
> > > +static int do_gpf(unsigned long far, unsigned long esr, struct pt_regs *regs)
> > > +{
> > > +	if (!is_el1_instruction_abort(esr) && fixup_exception(regs, esr))
> > > +		return 0;
> > > +
> > > +	return 1;
> > > +}
> > 
> > Is there a valid case for fixup_exception() here? IOW, do we ever have a
> > valid user mapping of the pages delegated to a guest? If the above is
> > considered a kernel bug, I'd not silently ignore this (like return less
> > bytes copied or -EFAULT to user) but rather warn, potentially
> > rate-limited.
> 
> Good question. This shouldn't be a valid case. We expect the VMM to use
> guest_memfd and that should prevent any mmaps and thus fixups shouldn't
> be required. That said, this series doesn't enforce that the VMM uses
> GMEM backed memslots for Guest RAM. We should probably do that while
> mapping things in.
> 
> With that, we could drop that fixup and scream a bit.
> 

There is a valid case for fixup_exception() to be needed here in GPF
handling.

-000 |load_unaligned_zeropad(inline)
-000 |hash_name(inline)
-000 |link_path_walk()
-001 |path_lookupat()
-002 |filename_lookup()
-003 |vfs_statx()
-004 |vfs_fstatat()

We observed this in Android running Gunyah when the page is mapped in
EL1 but unmapped at EL2. path_lookupat() can actually handle this
via fixup_exeption() when a word load crosses the page boundary.
However, Gunyah injects a Synchronous External Abort and we have
a downstream patch [1] that adds fixup_exception() in do_sea(). pKVM
injects [2] such faults back to EL1 and fixup_exception() is taken care.

This patch allows Hypervisors like Gunyah to simulate GPF instead of
Synchronous External Abort for kernel to gracefully handle the 
load_unaligned_zeropad() access.

Thanks,
Pavan


[1] https://android-review.googlesource.com/c/kernel/common/+/2996781
[2] https://lore.kernel.org/all/20260330144841.26181-20-will@kernel.org/