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]
Date:   Wed, 9 Nov 2016 15:17:09 -0700
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Will Deacon <will.deacon@....com>
Cc:     Christoffer Dall <christoffer.dall@...aro.org>,
        Don Dutile <ddutile@...hat.com>,
        Eric Auger <eric.auger@...hat.com>, eric.auger.pro@...il.com,
        marc.zyngier@....com, robin.murphy@....com, joro@...tes.org,
        tglx@...utronix.de, jason@...edaemon.net,
        linux-arm-kernel@...ts.infradead.org, kvm@...r.kernel.org,
        drjones@...hat.com, linux-kernel@...r.kernel.org,
        pranav.sawargaonkar@...il.com, iommu@...ts.linux-foundation.org,
        punit.agrawal@....com, diana.craciun@....com,
        benh@...nel.crashing.org, arnd@...db.de, jcm@...hat.com,
        dwmw@...zon.co.uk
Subject: Re: Summary of LPC guest MSI discussion in Santa Fe

On Wed, 9 Nov 2016 20:31:45 +0000
Will Deacon <will.deacon@....com> wrote:
> On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall wrote:
> > 
> > (I suppose it's technically possible to get around this issue by letting
> > QEMU place RAM wherever it wants but tell the guest to never use a
> > particular subset of its RAM for DMA, because that would conflict with
> > the doorbell IOVA or be seen as p2p transactions.  But I think we all
> > probably agree that it's a disgusting idea.)  
> 
> Disgusting, yes, but Ben's idea of hotplugging on the host controller with
> firmware tables describing the reserved regions is something that we could
> do in the distant future. In the meantime, I don't think that VFIO should
> explicitly reject overlapping mappings if userspace asks for them.

I'm confused by the last sentence here, rejecting user mappings that
overlap reserved ranges, such as MSI doorbell pages, is exactly how
we'd reject hot-adding a device when we meet such a conflict.  If we
don't reject such a mapping, we're knowingly creating a situation that
potentially leads to data loss.  Minimally, QEMU would need to know
about the reserved region, map around it through VFIO, and take
responsibility (somehow) for making sure that region is never used for
DMA.  Thanks,

Alex

Powered by blists - more mailing lists