[PATCH RFC v2 00/13] IOMMUFD Generic interface

Jason Gunthorpe jgg at nvidia.com
Wed Oct 12 14:59:38 UTC 2022

On Wed, Oct 12, 2022 at 10:55:57AM -0400, Steven Sistare wrote:
> On 10/12/2022 10:40 AM, Jason Gunthorpe wrote:
> > On Wed, Oct 12, 2022 at 09:50:53AM -0400, Steven Sistare wrote:
> > 
> >>> Anyhow, I think this conversation has convinced me there is no way to
> >>> fix VFIO_DMA_UNMAP_FLAG_VADDR. I'll send a patch reverting it due to
> >>> it being a security bug, basically.
> >>
> >> Please do not.  Please give me the courtesy of time to develop a replacement 
> >> before we delete it. Surely you can make progress on other opens areas of iommufd
> >> without needing to delete this immediately.
> > 
> > I'm not worried about iommufd, I'm worried about shipping kernels with
> > a significant security problem backed into them.
> > 
> > As we cannot salvage this interface it should quickly deleted so that
> > it doesn't cause any incidents.
> > 
> > It will not effect your ability to create a replacement.
> I am not convinced we cannot salvage the interface, and indeed I might want to reuse
> parts of it, and you are over-stating the risk of a feature that is already in 
> millions of kernels and has been for years. Deleting it all before having a
> replacement hurts the people like myself who are continuing to develop and test
> live update in qemu on the latest kernels.

I think this is a mistake, as I'm convinced it cannot be salvaged, but
we could instead guard it by a config symbol and CONFIG_EXPERIMENTAL.


More information about the libvir-list mailing list