[PATCH v2 5/7] arm64: mm: Add confidential computing hook to ioremap_prot()
Will Deacon
will at kernel.org
Wed Sep 4 05:29:48 PDT 2024
On Mon, Sep 02, 2024 at 08:08:45PM +0100, Catalin Marinas wrote:
> On Fri, Aug 30, 2024 at 02:01:48PM +0100, Will Deacon wrote:
> > @@ -16,7 +28,16 @@ void __iomem *ioremap_prot(phys_addr_t phys_addr, size_t size,
> > if (WARN_ON(pfn_is_map_memory(__phys_to_pfn(phys_addr))))
> > return NULL;
> >
> > - return generic_ioremap_prot(phys_addr, size, __pgprot(prot));
> > + /*
> > + * If a hook is registered (e.g. for confidential computing
> > + * purposes), call that now and barf if it fails.
> > + */
> > + if (unlikely(ioremap_prot_hook) &&
> > + WARN_ON(ioremap_prot_hook(phys_addr, size, &pgprot))) {
> > + return NULL;
> > + }
> > +
> > + return generic_ioremap_prot(phys_addr, size, pgprot);
> > }
> > EXPORT_SYMBOL(ioremap_prot);
>
> I mentioned on the CCA series, the patch is all good but we may need
> something similar for io_remap_pfn_range() which uses
> pgprot_decrypted() (I think it mostly matters for the pKVM case).
Thanks for pointing this out.
We've not needed this on Android yet, but I think that it would be
pretty straightforward to add with an arm64 definition of
io_remap_pfn_range(). I'd just prefer to leave that until we know that
we need it -- in all likelihood a driver would MMIO_GUARD the resources
as part of its own ioremap() before remapping into userspace.
Will
More information about the linux-arm-kernel
mailing list