linux-kernel - Re: [RFC PATCH v2 08/18] iommu/riscv: Use MSI table to enable IMSIC access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250923140646.GM1391379@nvidia.com>
Date: Tue, 23 Sep 2025 11:06:46 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Andrew Jones <ajones@...tanamicro.com>, iommu@...ts.linux.dev,
	kvm-riscv@...ts.infradead.org, kvm@...r.kernel.org,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
	zong.li@...ive.com, tjeznach@...osinc.com, joro@...tes.org,
	will@...nel.org, robin.murphy@....com, anup@...infault.org,
	atish.patra@...ux.dev, alex.williamson@...hat.com,
	paul.walmsley@...ive.com, palmer@...belt.com, alex@...ti.fr
Subject: Re: [RFC PATCH v2 08/18] iommu/riscv: Use MSI table to enable IMSIC
 access

On Tue, Sep 23, 2025 at 12:12:52PM +0200, Thomas Gleixner wrote:
> With a remapping domain intermediary this looks like this:
> 
>      [ CPU domain ] --- [ Remap domain] --- [ MSI domain ] -- device
>  
>    device driver allocates an MSI interrupt in the MSI domain
> 
>    MSI domain allocates an interrupt in the Remap domain
> 
>    Remap domain allocates a resource in the remap space, e.g. an entry
>    in the remap translation table and then allocates an interrupt in the
>    CPU domain.

Thanks!

And to be very crystal clear here, the meaning of
IRQ_DOMAIN_FLAG_ISOLATED_MSI is that the remap domain has a security
feature such that the device can only trigger CPU domain interrupts
that have been explicitly allocated in the remap domain for that
device. The device can never go through the remap domain and trigger
some other device's interrupt.

This is usally done by having the remap domain's HW take in the
Addr/Data pair, do a per-BDF table lookup and then completely replace
the Addr/Data pair with the "remapped" version. By fully replacing the
remap domain prevents the device from generating a disallowed
addr/data pair toward the CPU domain.

It fundamentally must be done by having the HW do a per-RID/BDF table
lookup based on the incoming MSI addr/data and fully sanitize the
resulting output.

There is some legacy history here. When MSI was first invented the
goal was to make interrupts scalable by removing any state from the
CPU side. The device would be told what Addr/Data to send to the CPU
and the CPU would just take some encoded information in that pair as a
delivery instruction. No state on the CPU side per interrupt.

In the world of virtualization it was realized this is not secure, so
the archs undid the core principal of MSI and the CPU HW has some kind
of state/table entry for every single device interrupt source.

x86/AMD did this by having per-device remapping tables in their IOMMU
device context that are selected by incomming RID and effectively
completely rewrite the addr/data pair before it reaches the APIC. The
remap table alone now basically specifies where the interrupt is
delivered.

ARM doesn't do remapping, instead the interrupt controller itself has
a table that converts (BDF,Data) into a delivery instruction. It is
inherently secure.

That flag has nothing to do with affinity.

Jason