On Tue, Jun 09, 2026 at 03:12:11PM +0000, Pranjal Shrivastava wrote: > On Mon, Jun 08, 2026 at 03:16:40PM -0300, Jason Gunthorpe wrote: > > On Mon, Jun 08, 2026 at 10:49:29AM +0000, Pranjal Shrivastava wrote: > > > > > My point was that a FW exploit can meddle with the bitfields of the > > > ACS_CTRL to spoof and mis-report the ACS flags. > > > > Devices can also ignore the ACS flags. I don't think this is an area > > where we should be worrying about devices being actively hostile. > > I'm wondering what happens if we preserve IOMMU groups across a kexec, > but a switch's ACS capability is dropped or the ACS_RR bit gets cleared? > The incoming kernel assumes that it's the same ACS cap from the old one > > Now, the incoming kernel restores the groups assuming they're still > isolated, but the hardware no longer enforces it, silently allowing DMAs > & breaking isolation?
Again, to clarify, I'm aware that we aren't preserving IOMMU groups, the incoming kernel has to rebuild the groups. My concern is that if the ACS_RR bit is cleared during the kexec window, the produced grouping would be different than the old kernel. What happens if two devices on the same bridge were assigned to 2 different VMs? Thanks, Praan
