linux-kernel - Re: [PATCH 15/52] fuse: map virtio

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: <20181213204052.GE4384@redhat.com>
Date:   Thu, 13 Dec 2018 15:40:52 -0500
From:   Vivek Goyal <vgoyal@...hat.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        KVM list <kvm@...r.kernel.org>,
        Miklos Szeredi <miklos@...redi.hu>,
        Stefan Hajnoczi <stefanha@...hat.com>, sweil@...hat.com,
        Steven Whitehouse <swhiteho@...hat.com>
Subject: Re: [PATCH 15/52] fuse: map virtio_fs DAX window BAR

On Thu, Dec 13, 2018 at 12:15:51PM -0800, Dan Williams wrote:
> On Thu, Dec 13, 2018 at 12:09 PM Dr. David Alan Gilbert
> <dgilbert@...hat.com> wrote:
> >
> > * Dan Williams (dan.j.williams@...el.com) wrote:
> > > On Mon, Dec 10, 2018 at 9:22 AM Vivek Goyal <vgoyal@...hat.com> wrote:
> > > >
> > > > From: Stefan Hajnoczi <stefanha@...hat.com>
> > > >
> > > > Experimental QEMU code introduces an MMIO BAR for mapping portions of
> > > > files in the virtio-fs device.  Map this BAR so that FUSE DAX can access
> > > > file contents from the host page cache.
> > >
> > > FUSE DAX sounds terrifying, can you explain a bit more about what this is?
> >
> > We've got a guest running in QEMU, it sees an emulated PCI device;
> > that runs a FUSE protocol over virtio on that PCI device, but also has
> > a trick where via commands sent over the virtio queue associated with that device,
> > (fragments of) host files get mmap'd into the qemu virtual memory that corresponds
> > to the kvm slot exposed to the guest for that bar.
> >
> > The guest sees those chunks in that BAR, and thus you can read/write
> > to the host file by directly writing into that BAR.
> 
> Ok so it's all software emulated and there won't be hardware DMA
> initiated by the guest to that address?

That's my understanding.

> I.e. if the host file gets
> truncated / hole-punched the guest would just cause a refault and the
> filesystem could fill in the block,

Right

> or the guest is expected to die if
> the fault to the truncated file range results in SIGBUS.

Are you referring to the case where a file page is mapped in qemu and
another guest/process trucates that page and when qemu tries to access it it
will get SIGBUS. Have not tried it, will give it a try. Not sure what
happens when QEMU receives SIGBUS.

Having said that, this is not different from the case of one process
mapping a file and another process truncating the file and first process
getting SIGBUS, right?

Thanks
Vivek

> 
> > > > The DAX window is accessed by the fs/dax.c infrastructure and must have
> > > > struct pages (at least on x86).  Use devm_memremap_pages() to map the
> > > > DAX window PCI BAR and allocate struct page.
> > >
> > > PCI BAR space is not cache coherent,
> >
> > Note that no real PCI infrastructure is involved - this is all emulated
> > devices, backed by mmap'd files on the host qemu process.
> 
> Ok, terror level decreased.