netdev - Re: [PATCH V4 vfio 04/10] vfio: Add an IOVA bitmap support

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <YwjDWqNblA2gZRpi@nvidia.com>
Date:   Fri, 26 Aug 2022 09:58:02 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     Yishai Hadas <yishaih@...dia.com>, saeedm@...dia.com,
        kvm@...r.kernel.org, netdev@...r.kernel.org, kuba@...nel.org,
        kevin.tian@...el.com, joao.m.martins@...cle.com, leonro@...dia.com,
        maorg@...dia.com, cohuck@...hat.com
Subject: Re: [PATCH V4 vfio 04/10] vfio: Add an IOVA bitmap support

On Thu, Aug 25, 2022 at 01:27:01PM -0600, Alex Williamson wrote:

> > +	/* length of the IOVA range for the whole bitmap */
> > +	unsigned long length;
> 
> OTOH this could arguably be size_t and iova dma_addr_t.  Thanks,

iova, for the purposes of iommu, is always unsigned long:

	int (*map)(struct iommu_domain *domain, unsigned long iova,
		   phys_addr_t paddr, size_t size, int prot, gfp_t gfp);

The use of dma_addr_t is something vfio does, which is sort of
problematic because vfio also assumes that dma_addr_t can safely be
implicitly cast to unsigned long, and on some 32 bit configurations
this is not true.

As this is intended to move to the drives/iommu some day it should
remain aligned to the iommu scheme.

And also make sure there are the proper checks when casting from u64
at the uAPI boundary to unsigned long internally that the user
provided u64 doesn't overflow the unsigned long.

Jason