linux-kernel - Re: [PATCH 0/3] iopmem : A block device for PCIe memory

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:   Fri, 21 Oct 2016 10:22:39 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Stephen Bates <sbates@...thlin.com>
Cc:     Dan Williams <dan.j.williams@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        linux-rdma@...r.kernel.org, linux-block@...r.kernel.org,
        Linux MM <linux-mm@...ck.org>,
        Ross Zwisler <ross.zwisler@...ux.intel.com>,
        Matthew Wilcox <willy@...ux.intel.com>,
        jgunthorpe@...idianresearch.com, haggaie@...lanox.com,
        Christoph Hellwig <hch@...radead.org>,
        Jens Axboe <axboe@...com>, Jonathan Corbet <corbet@....net>,
        jim.macdonald@...rspin.com, sbates@...thin.com,
        Logan Gunthorpe <logang@...tatee.com>,
        David Woodhouse <dwmw2@...radead.org>,
        "Raj, Ashok" <ashok.raj@...el.com>
Subject: Re: [PATCH 0/3] iopmem : A block device for PCIe memory

On Wed, Oct 19, 2016 at 12:48:14PM -0600, Stephen Bates wrote:
> On Tue, Oct 18, 2016 at 08:51:15PM -0700, Dan Williams wrote:
> > [ adding Ashok and David for potential iommu comments ]
> >
> 
> Hi Dan
> 
> Thanks for adding Ashok and David!
> 
> >
> > I agree with the motivation and the need for a solution, but I have
> > some questions about this implementation.
> >
> > >
> > > Consumers
> > > ---------
> > >
> > > We provide a PCIe device driver in an accompanying patch that can be
> > > used to map any PCIe BAR into a DAX capable block device. For
> > > non-persistent BARs this simply serves as an alternative to using
> > > system memory bounce buffers. For persistent BARs this can serve as an
> > > additional storage device in the system.
> >
> > Why block devices?  I wonder if iopmem was initially designed back
> > when we were considering enabling DAX for raw block devices.  However,
> > that support has since been ripped out / abandoned.  You currently
> > need a filesystem on top of a block-device to get DAX operation.
> > Putting xfs or ext4 on top of PCI-E memory mapped range seems awkward
> > if all you want is a way to map the bar for another PCI-E device in
> > the topology.
> >
> > If you're only using the block-device as a entry-point to create
> > dax-mappings then a device-dax (drivers/dax/) character-device might
> > be a better fit.
> >
> 
> We chose a block device because we felt it was intuitive for users to
> carve up a memory region but putting a DAX filesystem on it and creating
> files on that DAX aware FS. It seemed like a convenient way to
> partition up the region and to be easily able to get the DMA address
> for the memory backing the device.

You do realise that local filesystems can silently change the
location of file data at any point in time, so there is no such
thing as a "stable mapping" of file data to block device addresses
in userspace?

If you want remote access to the blocks owned and controlled by a
filesystem, then you need to use a filesystem with a remote locking
mechanism to allow co-ordinated, coherent access to the data in
those blocks. Anything else is just asking for ongoing, unfixable
filesystem corruption or data leakage problems (i.e.  security
issues).

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com