[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