[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

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

[Suzuki K Poulose]

On 17/09/2026 11:36, Catalin Marinas wrote:
> 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.

Yes, like I said, that seems to have lost. I will put that back in. This
is not in the v18/v19, but will add it for the next iteration.

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

Correct. For CCA, we can mandate that the private faults are only
faulted in from gmem memslots or the "trusted device private" memslots
when we eventually get the DA support.

I will address this for v20 of the integration series

Cheers
Suzuki



> 

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

[Suzuki K Poulose]

On 17/09/2026 11:36, Catalin Marinas wrote:
> 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.


I had another look and we could handle this via 
kvm_fault_is_gmem_abort() see in arch/arm64/kvm/mmu.c:


diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 87e49251e0447..af5a4bf961aae 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1731,6 +1731,9 @@ static int gmem_abort(const struct 
kvm_s2_fault_desc *s2fd)
         gfn_t gfn;
         int ret;

+       if (!kvm_slot_has_gmem(s2fd->memslot))
+               return -EINVAL;
+
         if (!perm_fault) {
                 memcache = get_mmu_memcache(vcpu);
                 ret = topup_mmu_memcache(vcpu, memcache);
@@ -2277,10 +2280,12 @@ static bool private_ipa_fault(struct kvm *kvm, 
phys_addr_t fault_ipa);
  static bool kvm_fault_is_gmem_abort(struct kvm *kvm,
                                     const struct kvm_s2_fault_desc *s2fd)
  {
-       if (!kvm_slot_has_gmem(s2fd->memslot))
-               return false;
         if (kvm_memslot_is_gmem_only(s2fd->memslot))
                 return true;
+       /*
+        * For Realms, all private faults must be backed by GMEM.
+        * TODO: Handle Trusted device private memory mappings.
+        */
         if (private_ipa_fault(kvm, s2fd->fault_ipa))
                 return true;
         return false;




Also, I have the following hunk for preventing memslot modifications.
I will add this to v20 integration branch, which is almost ready ;-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 582b48e34486b..87e49251e0447 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -2783,6 +2783,18 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
         }
  }

+static bool kvm_prevents_memslot_change(struct kvm *kvm, enum 
kvm_mr_change change)
+{
+       /* Cannot modify memslots once a pVM has run or Realm created */
+       if (change != KVM_MR_DELETE && change != KVM_MR_MOVE)
+               return false;
+
+       if ((kvm_vm_is_protected_pkvm(kvm) && 
pkvm_hyp_vm_is_created(kvm)) ||
+            kvm_realm_is_created(kvm))
+               return true;
+       return false;
+}
+
  int kvm_arch_prepare_memory_region(struct kvm *kvm,
                                    const struct kvm_memory_slot *old,
                                    struct kvm_memory_slot *new,
@@ -2791,12 +2803,9 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
         hva_t hva, reg_end;
         int ret = 0;

-       if (kvm_vm_is_protected_pkvm(kvm)) {
-               /* Cannot modify memslots once a pVM has run. */
-               if (pkvm_hyp_vm_is_created(kvm) &&
-                   (change == KVM_MR_DELETE || change == KVM_MR_MOVE)) {
+       if (kvm_vm_is_protected(kvm)) {
+               if (kvm_prevents_memslot_change(kvm, change))
                         return -EPERM;
-               }

                 if (new &&
                     new->flags & (KVM_MEM_LOG_DIRTY_PAGES | 
KVM_MEM_READONLY)) {
diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
index fc0297103f08b..6ec4e4487dff9 100644
--- a/arch/arm64/kvm/rmi.c
+++ b/arch/arm64/kvm/rmi.c
@@ -1596,6 +1596,7 @@ int kvm_activate_realm(struct kvm *kvm)
         if (kvm_realm_state(kvm) >= REALM_STATE_ACTIVE)
                 return 0;

+       guard(mutex)(&kvm->slots_lock);
         guard(mutex)(&kvm->arch.config_lock);
         /* Check again with the lock held */
         if (kvm_realm_state(kvm) >= REALM_STATE_ACTIVE)


Cheers
Suzuki

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

[Catalin Marinas]

On Tue, Sep 22, 2026 at 02:21:13PM +0100, Suzuki K Poulose wrote:
> I had another look and we could handle this via kvm_fault_is_gmem_abort()
> see in arch/arm64/kvm/mmu.c:
> 
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 87e49251e0447..af5a4bf961aae 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1731,6 +1731,9 @@ static int gmem_abort(const struct kvm_s2_fault_desc
> *s2fd)
>         gfn_t gfn;
>         int ret;
> 
> +       if (!kvm_slot_has_gmem(s2fd->memslot))
> +               return -EINVAL;

I wonder whether we should add a KVM_BUG_ON() here. With the rest of the
changes, we should never get in this situation. Well, to be revisited
for private devices.

Also maybe move it to the caller, kvm_vm_mem_abort(), and not change
kvm_fault_is_gmem_abort(). Something like:

	if (private_ipa_fault(kvm, s2fd->fault_ipa) &&
	    KVM_BUG_ON(!kvm_slot_has_gmem(s2fd->memslot), kvm))
		return -EIO;

To me it makes more sense for gmem_abort() to be called only *if* it's a
gmem slot. So any inconsistency, avoiding user_mem_abort() for private
memory, should be done in the caller. I assume the caller will also have
to route the private device path as well rather than rely on
gmem_abort().

> +
>         if (!perm_fault) {
>                 memcache = get_mmu_memcache(vcpu);
>                 ret = topup_mmu_memcache(vcpu, memcache);
> @@ -2277,10 +2280,12 @@ static bool private_ipa_fault(struct kvm *kvm,
> phys_addr_t fault_ipa);
>  static bool kvm_fault_is_gmem_abort(struct kvm *kvm,
>                                     const struct kvm_s2_fault_desc *s2fd)
>  {
> -       if (!kvm_slot_has_gmem(s2fd->memslot))
> -               return false;
>         if (kvm_memslot_is_gmem_only(s2fd->memslot))
>                 return true;
> +       /*
> +        * For Realms, all private faults must be backed by GMEM.
> +        * TODO: Handle Trusted device private memory mappings.
> +        */
>         if (private_ipa_fault(kvm, s2fd->fault_ipa))
>                 return true;
>         return false;
> 
> 
> Also, I have the following hunk for preventing memslot modifications.
> I will add this to v20 integration branch, which is almost ready ;-)
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 582b48e34486b..87e49251e0447 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -2783,6 +2783,18 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
>         }
>  }
> 
> +static bool kvm_prevents_memslot_change(struct kvm *kvm, enum kvm_mr_change change)
> +{
> +       /* Cannot modify memslots once a pVM has run or Realm created */
> +       if (change != KVM_MR_DELETE && change != KVM_MR_MOVE)
> +               return false;
> +
> +       if ((kvm_vm_is_protected_pkvm(kvm) && pkvm_hyp_vm_is_created(kvm)) ||
> +            kvm_realm_is_created(kvm))
> +               return true;
> +       return false;
> +}
> +
>  int kvm_arch_prepare_memory_region(struct kvm *kvm,
>                                    const struct kvm_memory_slot *old,
>                                    struct kvm_memory_slot *new,
> @@ -2791,12 +2803,9 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>         hva_t hva, reg_end;
>         int ret = 0;
> 
> -       if (kvm_vm_is_protected_pkvm(kvm)) {
> -               /* Cannot modify memslots once a pVM has run. */
> -               if (pkvm_hyp_vm_is_created(kvm) &&
> -                   (change == KVM_MR_DELETE || change == KVM_MR_MOVE)) {
> +       if (kvm_vm_is_protected(kvm)) {
> +               if (kvm_prevents_memslot_change(kvm, change))
>                         return -EPERM;
> -               }
> 
>                 if (new &&
>                     new->flags & (KVM_MEM_LOG_DIRTY_PAGES | KVM_MEM_READONLY)) {

I think this should work.

Thanks.

-- 
Catalin

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

[Suzuki K Poulose]

On 22/09/2026 15:49, Catalin Marinas wrote:
> On Tue, Sep 22, 2026 at 02:21:13PM +0100, Suzuki K Poulose wrote:
>> I had another look and we could handle this via kvm_fault_is_gmem_abort()
>> see in arch/arm64/kvm/mmu.c:
>>
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 87e49251e0447..af5a4bf961aae 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -1731,6 +1731,9 @@ static int gmem_abort(const struct kvm_s2_fault_desc
>> *s2fd)
>>          gfn_t gfn;
>>          int ret;
>>
>> +       if (!kvm_slot_has_gmem(s2fd->memslot))
>> +               return -EINVAL;
> 
> I wonder whether we should add a KVM_BUG_ON() here. With the rest of the
> changes, we should never get in this situation. Well, to be revisited
> for private devices.

Sure, I could add that

> 
> Also maybe move it to the caller, kvm_vm_mem_abort(), and not change
> kvm_fault_is_gmem_abort(). Something like:
> 
> 	if (private_ipa_fault(kvm, s2fd->fault_ipa) &&
> 	    KVM_BUG_ON(!kvm_slot_has_gmem(s2fd->memslot), kvm))
> 		return -EIO;
> 
> To me it makes more sense for gmem_abort() to be called only *if* it's a
> gmem slot. So any inconsistency, avoiding user_mem_abort() for private
> memory, should be done in the caller. I assume the caller will also have
> to route the private device path as well rather than rely on
> gmem_abort().

Agree.

> 
>> +
>>          if (!perm_fault) {
>>                  memcache = get_mmu_memcache(vcpu);
>>                  ret = topup_mmu_memcache(vcpu, memcache);
>> @@ -2277,10 +2280,12 @@ static bool private_ipa_fault(struct kvm *kvm,
>> phys_addr_t fault_ipa);
>>   static bool kvm_fault_is_gmem_abort(struct kvm *kvm,
>>                                      const struct kvm_s2_fault_desc *s2fd)
>>   {
>> -       if (!kvm_slot_has_gmem(s2fd->memslot))
>> -               return false;
>>          if (kvm_memslot_is_gmem_only(s2fd->memslot))
>>                  return true;
>> +       /*
>> +        * For Realms, all private faults must be backed by GMEM.
>> +        * TODO: Handle Trusted device private memory mappings.
>> +        */
>>          if (private_ipa_fault(kvm, s2fd->fault_ipa))
>>                  return true;
>>          return false;
>>
>>
>> Also, I have the following hunk for preventing memslot modifications.
>> I will add this to v20 integration branch, which is almost ready ;-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 582b48e34486b..87e49251e0447 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -2783,6 +2783,18 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
>>          }
>>   }
>>
>> +static bool kvm_prevents_memslot_change(struct kvm *kvm, enum kvm_mr_change change)
>> +{
>> +       /* Cannot modify memslots once a pVM has run or Realm created */
>> +       if (change != KVM_MR_DELETE && change != KVM_MR_MOVE)
>> +               return false;
>> +
>> +       if ((kvm_vm_is_protected_pkvm(kvm) && pkvm_hyp_vm_is_created(kvm)) ||
>> +            kvm_realm_is_created(kvm))
>> +               return true;
>> +       return false;
>> +}
>> +
>>   int kvm_arch_prepare_memory_region(struct kvm *kvm,
>>                                     const struct kvm_memory_slot *old,
>>                                     struct kvm_memory_slot *new,
>> @@ -2791,12 +2803,9 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>>          hva_t hva, reg_end;
>>          int ret = 0;
>>
>> -       if (kvm_vm_is_protected_pkvm(kvm)) {
>> -               /* Cannot modify memslots once a pVM has run. */
>> -               if (pkvm_hyp_vm_is_created(kvm) &&
>> -                   (change == KVM_MR_DELETE || change == KVM_MR_MOVE)) {
>> +       if (kvm_vm_is_protected(kvm)) {
>> +               if (kvm_prevents_memslot_change(kvm, change))
>>                          return -EPERM;
>> -               }
>>
>>                  if (new &&
>>                      new->flags & (KVM_MEM_LOG_DIRTY_PAGES | KVM_MEM_READONLY)) {
> 
> I think this should work.

Cheers
Suzuki

> 
> Thanks.
> 

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

[Will Deacon]

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.

Will