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

[Suzuki K Poulose]

On 23/09/2026 16:45, Will Deacon wrote:
> 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 at 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 at arm.com>
>>>> Reviewed-by: Gavin Shan <gshan at redhat.com>
>>>> Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
>>>> Signed-off-by: Steven Price <steven.price at arm.com>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose at 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.

There doesn't seem to be much progress on that series. Brendan
volunteered to resurrect the series, taking over from Nikita [0].
But looks like Brendan is not working on this anymore. Will see
if someone is really planning to look at it.

[0] https://lore.kernel.org/all/DJJ35VLH2PE5.DFD8OYXEOH97@linux.dev


>>
>> 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.

Agree, if the user mode can hit this, a page is mapped in the EL0 and
it can as well cause the Kernel to hit a GPF.
Also if make the handling unconditional, we end up calling
die_kernel_fault() and that does the mem_abort_decode() causing
duplicate logs.

Suzuki


> 
> Will