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

[Jason Gunthorpe <jgg@nvidia.com>]

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?

> > 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 ?

Jason