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

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:

quoted

On Sun, Sep 13, 2026 at 08:04:58AM +0100, Suzuki K Poulose wrote:

quoted

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.

quoted

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