Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Pankaj Gupta <pagupta@redhat.com>,
	jack@suse.cz, kvm@vger.kernel.org, linux-nvdimm@ml01.01.org,
	qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
	adilger.kernel@dilger.ca, zwisler@kernel.org, eblake@redhat.com,
	Andrea Arcangeli <aarcange@redhat.com>,
	dave.jiang@intel.com, darrick.wong@oracle.com,
	vishal.l.verma@intel.com, willy@infradead.org, hch@infradead.org,
	linux-acpi@vger.kernel.org, jmoyer@redhat.com, nilal@redhat.com,
	riel@surriel.com, stefanha@redhat.com, imammedo@redhat.com,
	dan.j.williams@intel.com, lcapitulino@redhat.com,
	linux-ext4@vger.kernel.org, tytso@mit.edu,
	xiaoguangrong.eric@gmail.com, rjw@rjwysocki.net,
	linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, pbonzini@redhat.com
Subject: Re: security implications of caching with virtio pmem (was Re: [PATCH v3 0/5] kvm "virtio pmem" device)
Date: Wed, 6 Feb 2019 13:01:36 -0500
Message-ID: <20190206125535-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <5b8a06a7-be44-698f-f319-6b2cbcf1eb8a@redhat.com>

On Wed, Feb 06, 2019 at 03:00:26PM +0100, David Hildenbrand wrote:
> On 04.02.19 23:56, Michael S. Tsirkin 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.  
> > 
> > 
> > At Pankaj's request I looked at information leak implications of virtio
> > pmem in light of the recent page cache side channels paper
> > (https://arxiv.org/pdf/1901.01161.pdf) - to see what
> > kind of side channels it might create if any.  TLDR - I think that
> > depending on the host side implementation there could be some, but this
> > might be addressable by better documentation in both code and spec.
> > The fake dax approach backing the guest memory by a host page cache
> > does seem to have potential issues.
> > 
> > For clarity: we are talking about leaking information either to a VM, or
> > within a VM (I did not look into leaks to hypervisor in configurations
> > such as SEV) through host page cache.
> > 
> > Leaks into a VM: It seems clear that while pmem allows memory accesses
> > versus read/write with e.g. a block device, from host page cache point
> > of view this doesn't matter much: reads populate cache in the same way
> > as memory faults.  Thus ignoring presence of information leaks (which is
> > an interesting question e.g. in light of recent discard support) pmem
> > doesn't seem to be any better or worse for leaking information into a
> > VM.
> 
> +1, just a different way to access that cache.
> 
> Conceptually a virtio-pmem devices is from the guest view a "device with
> a managed buffer". Some accesses might be faster than others. There are
> no guarantees on how fast a certain access is. And yes, actions on other
> guests can result in accesses being slower but not faster.
> 
> Also other storage devices have caches like that (well, the caches size
> depends on the device) - thinking especially about storage systems -
> which would in my opinion, also allow similar leaks. How are such
> security concerns handled there? Are they different (besides eventually
> access speed)?
> 
> > 
> > Leaks within VM: Right now pmem seems to bypass the guest page cache
> > completely.  Whether pmem memory is then resident in a page cache would
> > be up to the device/host. Assuming that it is, the "Preventing
> > Efficient Eviction while Increasing the System Performance"
> > countermeasure for the page cache side channel attack would appear to
> > become ineffective with pmem. What is suggested is a per-process
> > management of the page cache, and host does not have visibility of
> > processes within a VM. Another possible countermeasure - not discussed
> > in the paper - could be modify the applications to lock the security
> > relevant pages in memory.  Again this becomes impractical with pmem as
> > host does not have visibility into that. However note that as long
> > as the only countermeasure linux uses is "Privileged Access"
> > (i.e. blocking mincore) nothing can be done as guest page cache
> > remains as vulnerable as host page cache.
> 
> This sounds very use-case specific. If I run a VM only with a very
> specific workload (say, a container running one application), I usually
> don't care about leaks within the VM. At least not leaks between
> applications ;)
> 
> In contrast, to running different applications (e.g. containers from
> different customers) on one system, I really care about leaks within a VM.

Clearly, not everyone cares about closing off information leaks.

> > 
> > 
> > Countermeasures: which host-side countermeasures can be designed would
> > depend on which countermeasures are used guest-side - we would need to
> > make sure they are not broken by pmem.  For "Preventing Efficient
> > Eviction while Increasing the System Performance" modifying the host
> > implementation to ensure that pmem device bypasses the host page cache
> > would seem to address the security problem.Similarly, ensuring that a
> > real memory device (e.g. DAX, RAM such as hugetlbfs, pmem for nested
> > virt) is used for pmem would make the memory locking countermeasure
> > work.  Whether with such limitations the device is still useful
> > performance wise is an open question.  These questions probably should
> > be addressed in the documentation, spec and possible qemu code.
> > 
> I also want to note that using a disk/file as memory backend with
> NVDIMMs in QEMU essentially results in the exact same questions we have
> with virtio-pmem.
> 
> E.g. kata-containers use nvdimms for the rootfile system (read-only) as
> far as I am aware.
> 
> Conceptually, a virtio-pmem device is just an emulated nvdimm device
> with a flush interface. And the nice thing is, that it is designed to
> also work on architectures that don't speak "nvdimm".
> 
> > 
> > Severity of the security implications: some people argue that the
> > security implications of the page cache leaks are minor.  I do not have
> > an opinion on this: the severity would seem to depend on the specific
> > configuration.
> 
> I guess configuration and use case.

Good point.

> Nice summary, thanks for looking into this Michael!
> 
> 
> -- 
> 
> Thanks,
> 
> David / dhildenb
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply index

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09 14:47 [PATCH v3 0/5] kvm "virtio pmem" device Pankaj Gupta
2019-01-09 14:47 ` [PATCH v3 1/5] libnvdimm: nd_region flush callback support Pankaj Gupta
2019-01-09 14:47 ` [PATCH v3 2/5] virtio-pmem: Add virtio pmem driver Pankaj Gupta
2019-01-14 15:54   ` Michael S. Tsirkin
2019-01-14 15:54     ` Michael S. Tsirkin
     [not found]     ` <20190114105314-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2019-01-15  6:33       ` Pankaj Gupta
2019-01-15  6:33         ` Pankaj Gupta
2019-01-09 14:47 ` [PATCH v3 3/5] libnvdimm: add nd_region buffered dax_dev flag Pankaj Gupta
2019-01-09 14:47 ` [PATCH v3 4/5] ext4: disable map_sync for virtio pmem Pankaj Gupta
2019-01-09 14:47 ` [PATCH v3 5/5] xfs: " Pankaj Gupta
2019-01-09 14:47   ` Pankaj Gupta
2019-01-09 16:26   ` Darrick J. Wong
2019-01-09 18:08     ` Pankaj Gupta
     [not found] ` <20190109144736.17452-1-pagupta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-10  1:26   ` [PATCH v3 0/5] kvm "virtio pmem" device Dave Chinner
2019-01-10  1:26     ` Dave Chinner
2019-01-10  2:40     ` Rik van Riel
2019-01-10  2:40       ` Rik van Riel
2019-01-10 10:17     ` Jan Kara
2019-01-10 10:17       ` Jan Kara
     [not found]       ` <20190110101757.GC15790-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2019-01-13  1:38         ` Pankaj Gupta
2019-01-13  1:38           ` Pankaj Gupta
     [not found]           ` <1354249849.63357171.1547343519970.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-13  1:43             ` Dan Williams
2019-01-13  1:43               ` Dan Williams
     [not found]               ` <CAPcyv4hwcgTUpgNCefCGu4DvgkYBp5b=f+hJ+FC=s5APYKoycg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-13  2:17                 ` [Qemu-devel] " Pankaj Gupta
2019-01-13  2:17                   ` Pankaj Gupta
     [not found]                   ` <540171952.63371441.1547345866585.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-14  9:55                     ` Jan Kara
2019-01-14  9:55                       ` Jan Kara
     [not found]                       ` <20190114095520.GC13316-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2019-01-14 10:16                         ` Pankaj Gupta
2019-01-14 10:16                           ` Pankaj Gupta
2019-01-11  7:45     ` Pankaj Gupta
2019-01-11  7:45       ` Pankaj Gupta
     [not found]       ` <1326478078.61913951.1547192704870.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-13 23:29         ` Dave Chinner
2019-01-13 23:29           ` Dave Chinner
2019-01-13 23:38           ` Matthew Wilcox
2019-01-13 23:38             ` Matthew Wilcox
     [not found]             ` <20190113233820.GX6310-PfSpb0PWhxZc2C7mugBRk2EX/6BAtgUQ@public.gmane.org>
2019-01-14  2:50               ` Dave Chinner
2019-01-14  2:50                 ` Dave Chinner
2019-01-14  7:15               ` Pankaj Gupta
2019-01-14  7:15                 ` Pankaj Gupta
     [not found]                 ` <942065073.64011540.1547450140670.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-14 21:25                   ` Dave Chinner
2019-01-14 21:25                     ` Dave Chinner
2019-01-14 21:35                     ` Dan Williams
2019-01-14 21:35                       ` Dan Williams
     [not found]                       ` <CAPcyv4jtPcLV-s0sKNHwwk0ug7GLBV6699dpm1h3r2xSo879dg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-14 22:21                         ` Dave Chinner
2019-01-14 22:21                           ` Dave Chinner
2019-01-15  2:19                           ` Michael S. Tsirkin
2019-01-15  2:19                             ` Michael S. Tsirkin
     [not found]                             ` <20190114205031-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2019-01-15  5:37                               ` [Qemu-devel] " Pankaj Gupta
2019-01-15  5:37                                 ` Pankaj Gupta
2019-01-15  5:35                           ` Pankaj Gupta
2019-01-15  5:35                             ` Pankaj Gupta
     [not found]                             ` <1684638419.64320214.1547530506805.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-15 20:42                               ` Dave Chinner
2019-01-15 20:42                                 ` Dave Chinner
2019-02-04 22:56 ` security implications of caching with virtio pmem (was Re: [PATCH v3 0/5] kvm "virtio pmem" device) Michael S. Tsirkin
2019-02-05  7:29   ` [Qemu-devel] " Pankaj Gupta
2019-02-06 14:00   ` David Hildenbrand
2019-02-06 18:01     ` Michael S. Tsirkin [this message]
2019-02-11  7:29   ` [Qemu-devel] " Pankaj Gupta
2019-02-11 22:29     ` Dave Chinner
2019-02-11 22:58       ` David Hildenbrand
2019-02-11 23:07         ` Michael S. Tsirkin

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190206125535-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=dan.j.williams@intel.com \
    --cc=darrick.wong@oracle.com \
    --cc=dave.jiang@intel.com \
    --cc=david@redhat.com \
    --cc=eblake@redhat.com \
    --cc=hch@infradead.org \
    --cc=imammedo@redhat.com \
    --cc=jack@suse.cz \
    --cc=jmoyer@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lcapitulino@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=nilal@redhat.com \
    --cc=pagupta@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=riel@surriel.com \
    --cc=rjw@rjwysocki.net \
    --cc=stefanha@redhat.com \
    --cc=tytso@mit.edu \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=vishal.l.verma@intel.com \
    --cc=willy@infradead.org \
    --cc=xiaoguangrong.eric@gmail.com \
    --cc=zwisler@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org linux-fsdevel@archiver.kernel.org
	public-inbox-index linux-fsdevel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox