netdev - RE: [PATCH V2 vfio 06/11] vfio: Introduce the DMA logging feature 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: <BN9PR11MB52765A281BFF7C87523643BB8C949@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Tue, 26 Jul 2022 07:34:55 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>
CC:     Alex Williamson <alex.williamson@...hat.com>,
        Yishai Hadas <yishaih@...dia.com>,
        "saeedm@...dia.com" <saeedm@...dia.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "Martins, Joao" <joao.m.martins@...cle.com>,
        "leonro@...dia.com" <leonro@...dia.com>,
        "maorg@...dia.com" <maorg@...dia.com>,
        "cohuck@...hat.com" <cohuck@...hat.com>
Subject: RE: [PATCH V2 vfio 06/11] vfio: Introduce the DMA logging feature
 support

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Monday, July 25, 2022 10:37 PM
> 
> On Mon, Jul 25, 2022 at 07:38:52AM +0000, Tian, Kevin wrote:
> 
> > > Yes. qemu has to select a static aperture at start.
> > >
> > >  The entire aperture is best, if that fails
> > >
> > >  A smaller aperture and hope the guest doesn't use the whole space, if
> > >  that fails,
> > >
> > >  The entire guest physical map and hope the guest is in PT mode
> >
> > That sounds a bit hacky... does it instead suggest that an interface
> > for reporting the supported ranges on a tracker could be helpful once
> > trying the entire aperture fails?
> 
> It is the "try and fail" approach. It gives the driver the most
> flexability in processing the ranges to try and make them work. If we
> attempt to describe all the device constraints that might exist we
> will be here forever.

Usually the caller of a 'try and fail' interface knows exactly what to
be tried and then call the interface to see whether the callee can
meet its requirement.

Now above turns out to be a 'guess and fail' approach with which
the caller doesn't know exactly what should be tried. In this case
even if the attempt succeeds it's a question how helpful it is.

But I can see why a reporting mechanism doesn't fit well with
your example below. In the worst case probably the user has to
decide between using vIOMMU vs. vfio DMA logging if a simple
policy of using the entire aperture doesn't work...

> 
> Eg the driver might be able to do the entire aperture, but it has to
> use 2M pages or something.
>