Re: [PATCH v16 07/45] arm64: mm: Handle Granule Protection Faults (GPFs)
From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2026-08-11 14:44:59
Also in:
kvm, kvmarm, linux-coco, lkml
On Mon, Aug 03, 2026 at 02:43:23PM +0100, Steven Price wrote:
quoted hunk ↗ jump to hunk
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@arm.com> Reviewed-by: Gavin Shan <redacted> Signed-off-by: Steven Price <steven.price@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. If there is a real use-case for this, what's preventing GUP + memcpy() from triggering a similar fault with no fixup available? -- Catalin