Re: [PATCH iommufd 1/9] irq: Add msi_device_has_secure_msi()

[Marc Zyngier <maz@kernel.org>]

On Fri, 09 Dec 2022 14:10:54 +0000,
Jason Gunthorpe <jgg@nvidia.com> wrote:
> 
> On Fri, Dec 09, 2022 at 01:59:35PM +0000, Marc Zyngier wrote:
> > On Thu, 08 Dec 2022 20:26:28 +0000,
> > Jason Gunthorpe <jgg@nvidia.com> wrote:
> > > 
> > > This will replace irq_domain_check_msi_remap() in following patches.
> > > 
> > > The new API makes it more clear what "msi_remap" actually means from a
> > > functional perspective instead of identifying an implementation specific
> > > HW feature.
> > > 
> > > Secure MSI means that an irq_domain on the path from the initiating device
> > 
> > irq_domain is a SW construct, and you are trying to validate something
> > that is HW property.
> 
> Sure, but the SW constructs model the HW functions, so yes this is
> trying to say that the irq_domain is modeling HW that does this.
> 
> > "Secure" is also a terribly overloaded term that means very different
> > things in non-x86 circles. 
> 
> Here it is being used as a software property - it is security safe to
> allow device operation outside the kernel.
> 
> > When I read this, I see an ARM system with
> > a device generating an MSI with the "secure" bit set as part of the
> > transaction and identifying the memory access as being part of the
> > "secure" domain.
> 
> Is that secure meaning "confidential" or some other ARM thing?

In ARM parlance, "secure" denotes the secure *physical address space*,
which is a totally disconnected PA space from the "normal" PA space.

If on top of that you have had an unhealthy helping of the
"confidential computing" kool-aid, you get another 2 extra physical
address spaces ("root" and "realm").

> 
> > > number that the initiating device is authorized to trigger. Secure MSI
> > > must block devices from triggering interrupts they are not authorized to
> > > trigger. Currently authorization means the MSI vector is one assigned to
> > > the device.
> > 
> > What you are describing here is a *device isolation* property, and I'd
> > rather we stay away from calling that "secure". If anything, I'd
> > rather call everything else "broken".
> 
> Sure, so
> 
> msi_device_isolated_interrupts() 
> 
> And related ?

Sure.

	M.

-- 
Without deviation from the norm, progress is not possible.