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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20190113233820.GX6310@bombadil.infradead.org>
Date:   Sun, 13 Jan 2019 15:38:21 -0800
From:   Matthew Wilcox <willy@...radead.org>
To:     Dave Chinner <david@...morbit.com>
Cc:     Pankaj Gupta <pagupta@...hat.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, jack@...e.cz, 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,
        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 Mon, Jan 14, 2019 at 10:29:02AM +1100, Dave Chinner wrote:
> Until you have images (and hence host page cache) shared between
> multiple guests. People will want to do this, because it means they
> only need a single set of pages in host memory for executable
> binaries rather than a set of pages per guest. Then you have
> multiple guests being able to detect residency of the same set of
> pages. If the guests can then, in any way, control eviction of the
> pages from the host cache, then we have a guest-to-guest information
> leak channel.

I don't think we should ever be considering something that would allow a
guest to evict page's from the host's pagecache [1].  The guest should
be able to kick its own references to the host's pagecache out of its
own pagecache, but not be able to influence whether the host or another
guest has a read-only mapping cached.

[1] Unless the guest is allowed to modify the host's file; obviously
truncation, holepunching, etc are going to evict pages from the host's
page cache.