linux-ext4 - Re: [PATCH v3 0/5] kvm "virtio pmem" device

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1354249849.63357171.1547343519970.JavaMail.zimbra@redhat.com>
Date:   Sat, 12 Jan 2019 20:38:39 -0500 (EST)
From:   Pankaj Gupta <pagupta@...hat.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Dave Chinner <david@...morbit.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, qemu-devel@...gnu.org,
        linux-nvdimm@...1.01.org, linux-fsdevel@...r.kernel.org,
        virtualization@...ts.linux-foundation.org,
        linux-acpi@...r.kernel.org, linux-ext4@...r.kernel.org,
        linux-xfs@...r.kernel.org, stefanha@...hat.com,
        dan j williams <dan.j.williams@...el.com>, riel@...riel.com,
        nilal@...hat.com, kwolf@...hat.com, pbonzini@...hat.com,
        zwisler@...nel.org, vishal l verma <vishal.l.verma@...el.com>,
        dave jiang <dave.jiang@...el.com>, david@...hat.com,
        jmoyer@...hat.com,
        xiaoguangrong eric <xiaoguangrong.eric@...il.com>,
        hch@...radead.org, mst@...hat.com, jasowang@...hat.com,
        lcapitulino@...hat.com, imammedo@...hat.com, eblake@...hat.com,
        willy@...radead.org, tytso@....edu,
        adilger kernel <adilger.kernel@...ger.ca>,
        darrick wong <darrick.wong@...cle.com>, rjw@...ysocki.net
Subject: Re: [PATCH v3 0/5] kvm "virtio pmem" device



> 
> On Thu 10-01-19 12:26:17, Dave Chinner wrote:
> > On Wed, Jan 09, 2019 at 08:17:31PM +0530, Pankaj Gupta wrote:
> > >  This patch series has implementation for "virtio pmem".
> > >  "virtio pmem" is fake persistent memory(nvdimm) in guest
> > >  which allows to bypass the guest page cache. This also
> > >  implements a VIRTIO based asynchronous flush mechanism.
> > 
> > Hmmmm. Sharing the host page cache direct into the guest VM. Sounds
> > like a good idea, but.....
> > 
> > This means the guest VM can now run timing attacks to observe host
> > side page cache residency, and depending on the implementation I'm
> > guessing that the guest will be able to control host side page
> > cache eviction, too (e.g. via discard or hole punch operations).
> > 
> > Which means this functionality looks to me like a new vector for
> > information leakage into and out of the guest VM via guest
> > controlled host page cache manipulation.
> > 
> > https://arxiv.org/pdf/1901.01161
> > 
> > I might be wrong, but if I'm not we're going to have to be very
> > careful about how guest VMs can access and manipulate host side
> > resources like the page cache.....
> 
> Right. Thinking about this I would be more concerned about the fact that
> guest can effectively pin amount of host's page cache upto size of the
> device/file passed to guest as PMEM, can't it Pankaj? Or is there some QEMU
> magic that avoids this?

Yes, guest will pin these host page cache pages using 'get_user_pages' by
elevating the page reference count. But these pages can be reclaimed by host
at any time when there is memory pressure.

KVM does not permanently pin pages. vfio does that but we are not using
it here.

Could you please elaborate what you are thinking?

Thanks,
Pankaj