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

[Catalin Marinas <catalin.marinas@arm.com>]

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