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

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

[Suzuki K Poulose]

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(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 75c3e463df2ef..dc3a87902a60c 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -914,6 +914,24 @@ 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);
+	unsigned long addr = untagged_addr(far);
+
+	die_kernel_fault(inf->name, addr, esr, regs);
+	return 0;
+}
+
+static int do_gpf(unsigned long far, unsigned long esr, struct pt_regs *regs)
+{
+	if (!user_mode(regs) && !is_el1_instruction_abort(esr) &&
+	    fixup_exception(regs, esr))
+		return 0;
+
+	return 1;
+}
+
 static const struct fault_info fault_info[] = {
 	{ do_bad,		SIGKILL, SI_KERNEL,	"ttbr address size fault"	},
 	{ do_bad,		SIGKILL, SI_KERNEL,	"level 1 address size fault"	},
@@ -950,12 +968,12 @@ static const struct fault_info fault_info[] = {
 	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 32"			},
 	{ do_alignment_fault,	SIGBUS,  BUS_ADRALN,	"alignment fault"		},
 	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 34"			},
-	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 35"			},
-	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 36"			},
-	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 37"			},
-	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 38"			},
-	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 39"			},
-	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 40"			},
+	{ do_gpf_ptw,		SIGKILL, SI_KERNEL,	"level -1 granule protection fault (translation table walk)" },
+	{ do_gpf_ptw,		SIGKILL, SI_KERNEL,	"level 0 granule protection fault (translation table walk)" },
+	{ do_gpf_ptw,		SIGKILL, SI_KERNEL,	"level 1 granule protection fault (translation table walk)" },
+	{ do_gpf_ptw,		SIGKILL, SI_KERNEL,	"level 2 granule protection fault (translation table walk)" },
+	{ do_gpf_ptw,		SIGKILL, SI_KERNEL,	"level 3 granule protection fault (translation table walk)" },
+	{ do_gpf,		SIGBUS,  BUS_OBJERR,	"granule protection fault" },
 	{ do_bad,		SIGKILL, SI_KERNEL,	"level -1 address size fault"	},
 	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 42"			},
 	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level -1 translation fault"	},
-- 
2.43.0

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

[Catalin Marinas]

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(-)
> 
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 75c3e463df2ef..dc3a87902a60c 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -914,6 +914,24 @@ 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);
> +	unsigned long addr = untagged_addr(far);
> +
> +	die_kernel_fault(inf->name, addr, esr, regs);
> +	return 0;
> +}
> +
> +static int do_gpf(unsigned long far, unsigned long esr, struct pt_regs *regs)
> +{
> +	if (!user_mode(regs) && !is_el1_instruction_abort(esr) &&
> +	    fixup_exception(regs, esr))
> +		return 0;
> +
> +	return 1;
> +}

We discussed briefly offline. With the latest patches around, would we
ever end up with private memory mapped in the VMM and hence the GPF? If
not, I would still keep this handling but add a
WARN_ON_ONCE(user_mode(regs)).

However, can we end up delegating a non-guest_memfd memslot page as
protected?

I played a bit with codex and it reckons it's possible if a guest_memfd
memslot is deleted after its IPA range has been initialised with
RIPAS=RAM. Removing the memslot unmaps and undelegates any data pages
but leaves the RMM state as RAM. The VMM can then install an ordinary
memslot over the same GPA range.

A subsequent private-IPA S2 fault sees the non-guest_memfd slot, takes
user_mem_abort(), GUPs the user page and passes it to
realm_map_protected(). The userspace mapping remains present, so a later
EL0 access can generate a GPF.

What's worse, I think it can even trick the kernel into doing a memcpy()
access (via GUP). Hmm, does such ordinary slot page even remain pinned?
There are other kernel parts that could access it.

I don't think it changes this patch but if the above is possible, we
should definitely get it tightened on the other series (and here we can
add the warning).

-- 
Catalin

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

[Catalin Marinas]

On Wed, Sep 16, 2026 at 05:39:31PM +0100, Catalin Marinas wrote:
> On Sun, Sep 13, 2026 at 08:04:58AM +0100, Suzuki K Poulose wrote:
> > +static int do_gpf(unsigned long far, unsigned long esr, struct pt_regs *regs)
> > +{
> > +	if (!user_mode(regs) && !is_el1_instruction_abort(esr) &&
> > +	    fixup_exception(regs, esr))
> > +		return 0;
> > +
> > +	return 1;
> > +}
> 
> We discussed briefly offline. With the latest patches around, would we
> ever end up with private memory mapped in the VMM and hence the GPF? If
> not, I would still keep this handling but add a
> WARN_ON_ONCE(user_mode(regs)).

Actually, even better:

	WARN_ON_ONCE(is_ttbr0_addr(untagged_addr(far)));

to capture uaccess. The user_mode() test you have above can stay the
same.

-- 
Catalin

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

[Catalin Marinas]

On Wed, Sep 16, 2026 at 05:39:24PM +0100, Catalin Marinas wrote:
> However, can we end up delegating a non-guest_memfd memslot page as
> protected?
> 
> I played a bit with codex and it reckons it's possible if a guest_memfd
> memslot is deleted after its IPA range has been initialised with
> RIPAS=RAM. Removing the memslot unmaps and undelegates any data pages
> but leaves the RMM state as RAM. The VMM can then install an ordinary
> memslot over the same GPA range.

After some more digging, I think RIPAS becomes DESTROYED after
undelegation but it doesn't change much. A subsequent guest access to
the private IPA still exits to the host which will attempt to delegate
it again even if it's no longer guest_memfd. RIPAS remains DESTROYED but
GPT is now REALM (and potentially a valid user mapping).

-- 
Catalin

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

[Suzuki K Poulose]

Hi Catalin

On 16/09/2026 17:39, Catalin Marinas 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(-)
>>
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index 75c3e463df2ef..dc3a87902a60c 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -914,6 +914,24 @@ 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);
>> +	unsigned long addr = untagged_addr(far);
>> +
>> +	die_kernel_fault(inf->name, addr, esr, regs);
>> +	return 0;
>> +}
>> +
>> +static int do_gpf(unsigned long far, unsigned long esr, struct pt_regs *regs)
>> +{
>> +	if (!user_mode(regs) && !is_el1_instruction_abort(esr) &&
>> +	    fixup_exception(regs, esr))
>> +		return 0;
>> +
>> +	return 1;
>> +}
> 
> We discussed briefly offline. With the latest patches around, would we
> ever end up with private memory mapped in the VMM and hence the GPF? If
> not, I would still keep this handling but add a
> WARN_ON_ONCE(user_mode(regs)).
> 
> However, can we end up delegating a non-guest_memfd memslot page as
> protected?
> 
> I played a bit with codex and it reckons it's possible if a guest_memfd
> memslot is deleted after its IPA range has been initialised with
> RIPAS=RAM. Removing the memslot unmaps and undelegates any data pages
> but leaves the RMM state as RAM. The VMM can then install an ordinary
> memslot over the same GPA range.

This should be prevented by the following predicates:

1) Realms only support guest_memfd backed memslots for mappable memory.
2) Memslots cannot be created after the Realm is created, as is with the
protected VMs. (This check seems to have been lost over the iterations,
  but should be reinstated).

> 
> A subsequent private-IPA S2 fault sees the non-guest_memfd slot, takes
> user_mem_abort(), GUPs the user page and passes it to
> realm_map_protected(). The userspace mapping remains present, so a later
> EL0 access can generate a GPF.

The Realm mem abort code should prevent this by ensuring that the
memslot is backed by gmem for private_faults. With the mandate of
in-place conversion, even the shared pages must come from the
gmem backed memslots.

> 
> What's worse, I think it can even trick the kernel into doing a memcpy()
> access (via GUP). Hmm, does such ordinary slot page even remain pinned?
> There are other kernel parts that could access it.
> 
> I don't think it changes this patch but if the above is possible, we
> should definitely get it tightened on the other series (and here we can
> add the warning).

Agreed. I will address these concerns in the kvm part2 of the CCA changes.

Cheers
Suzuki

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

[Catalin Marinas]

Hi Suzuki,

On Thu, Sep 17, 2026 at 10:03:14AM +0100, Suzuki K Poulose wrote:
> On 16/09/2026 17:39, Catalin Marinas wrote:
> > On Sun, Sep 13, 2026 at 08:04:58AM +0100, Suzuki K Poulose wrote:
> > > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > > index 75c3e463df2ef..dc3a87902a60c 100644
> > > --- a/arch/arm64/mm/fault.c
> > > +++ b/arch/arm64/mm/fault.c
> > > @@ -914,6 +914,24 @@ 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);
> > > +	unsigned long addr = untagged_addr(far);
> > > +
> > > +	die_kernel_fault(inf->name, addr, esr, regs);
> > > +	return 0;
> > > +}
> > > +
> > > +static int do_gpf(unsigned long far, unsigned long esr, struct pt_regs *regs)
> > > +{
> > > +	if (!user_mode(regs) && !is_el1_instruction_abort(esr) &&
> > > +	    fixup_exception(regs, esr))
> > > +		return 0;
> > > +
> > > +	return 1;
> > > +}
> > 
> > We discussed briefly offline. With the latest patches around, would we
> > ever end up with private memory mapped in the VMM and hence the GPF? If
> > not, I would still keep this handling but add a
> > WARN_ON_ONCE(user_mode(regs)).
> > 
> > However, can we end up delegating a non-guest_memfd memslot page as
> > protected?
> > 
> > I played a bit with codex and it reckons it's possible if a guest_memfd
> > memslot is deleted after its IPA range has been initialised with
> > RIPAS=RAM. Removing the memslot unmaps and undelegates any data pages
> > but leaves the RMM state as RAM. The VMM can then install an ordinary
> > memslot over the same GPA range.
> 
> This should be prevented by the following predicates:
> 
> 1) Realms only support guest_memfd backed memslots for mappable memory.
> 2) Memslots cannot be created after the Realm is created, as is with the
> protected VMs. (This check seems to have been lost over the iterations,
>  but should be reinstated).

If that's the intended model, I think it should work. But v18 doesn't
enforce either of them. I noticed the second predicate for pKVM only -
your 'Widen the scope of "protected" VMs' patch makes this restriction
explicit to pKVM.

For the first one, if !kvm_slot_has_gmem(), it simply continues with the
registration.

> > A subsequent private-IPA S2 fault sees the non-guest_memfd slot, takes
> > user_mem_abort(), GUPs the user page and passes it to
> > realm_map_protected(). The userspace mapping remains present, so a later
> > EL0 access can generate a GPF.
> 
> The Realm mem abort code should prevent this by ensuring that the
> memslot is backed by gmem for private_faults. With the mandate of
> in-place conversion, even the shared pages must come from the
> gmem backed memslots.

IIUC this only works if the memslot is gmem but I can't see what
prevents ordinary slots from being assigned to realms. I think we can
enter the user_mem_abort() -> realm_map_ipa() for ordinary slots unless
we prevent the deletion of the original slots and enforce gmem only
slots early.

-- 
Catalin