Re: [PATCH v16 07/45] arm64: mm: Handle Granule Protection Faults (GPFs)

[Will Deacon <will@kernel.org>]

On Fri, Aug 14, 2026 at 02:15:39PM +0530, Pavan Kondeti wrote:
> On Thu, Aug 13, 2026 at 04:28:04PM +0100, Will Deacon wrote:
> > On Thu, Aug 13, 2026 at 07:40:41PM +0530, Pavan Kondeti wrote:
> > > On Thu, Aug 13, 2026 at 11:11:03AM +0100, Will Deacon wrote:
> > > > On Wed, Aug 12, 2026 at 02:51:29PM +0100, Catalin Marinas wrote:
> > > > > On Wed, Aug 12, 2026 at 06:12:09PM +0530, Pavan Kondeti wrote:
> > > > > > There is a valid case for fixup_exception() to be needed here in GPF
> > > > > > handling.
> > > > > > 
> > > > > > -000 |load_unaligned_zeropad(inline)
> > > > > > -000 |hash_name(inline)
> > > > > > -000 |link_path_walk()
> > > > > > -001 |path_lookupat()
> > > > > > -002 |filename_lookup()
> > > > > > -003 |vfs_statx()
> > > > > > -004 |vfs_fstatat()
> > > > > > 
> > > > > > We observed this in Android running Gunyah when the page is mapped in
> > > > > > EL1 but unmapped at EL2. path_lookupat() can actually handle this
> > > > > > via fixup_exeption() when a word load crosses the page boundary.
> > > > > > However, Gunyah injects a Synchronous External Abort and we have
> > > > > > a downstream patch [1] that adds fixup_exception() in do_sea(). pKVM
> > > > > > injects [2] such faults back to EL1 and fixup_exception() is taken care.
> > > > > 
> > > > > Ah, good point, completely forgot about load_unaligned_zeropad(). Since
> > > > > we don't unmap the linear map for delegated pages, we'll need the
> > > > > fixup_exception(). And I guess warning in this case is not desirable
> > > > > either. We could limit it to EX_TYPE_KACCESS_ERR_ZERO and
> > > > > EX_TYPE_LOAD_UNALIGNED_ZEROPAD, though not sure it's worth it.
> > > > 
> > > > Alternatively, I think the series to unmap guest memory from the linear
> > > > map would solve that for gmem:
> > > > 
> > > > https://lore.kernel.org/all/20260410151746.61150-1-kalyazin@amazon.com/
> > > > 
> > > 
> > > Thanks Will for sharing this information.
> > > 
> > > There are use cases outside gmem like FF-A lend to Secure Partition.
> > > we may not be enforcing all such memory to be unmapped at EL1, correct?
> > 
> > If you leave the cacheable linear alias of memory intact across an
> > NS -> S transition, then you're in for a bad time [1].
> > 
> > Will
> > 
> > [1] https://lore.kernel.org/all/20221114110329.68413-1-manivannan.sadhasivam@linaro.org/
> 
> Thanks for the reply. In the above case, XPU does not like the speculative fetches. I am
> not sure if there is a hard requirement for unmap of FF_A memory lent to secure
> partition managed under Root with GPT.

If it's not unmapped, then you can get speculative reads on the NS side
which will probably trigger aborts at the TZ memory firewall logic. I
agree that's different for the GPT, but gmem is growing that support for
other architectures and it would solve the load_unaligned_zeropad()
problem on arm64. Some folks also seem to want it for addressing the
possibility of CPU side-channels, but that's a bit more belt and braces
imo.

Vincent looped you in on the thread with Thierry where there is an ongoing
effort to address this for TZ.

Will