From: Pankaj Gupta <pagupta@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: jack@suse.cz, kvm@vger.kernel.org, david@redhat.com,
linux-nvdimm@ml01.01.org, jasowang@redhat.com,
qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
adilger kernel <adilger.kernel@dilger.ca>,
zwisler@kernel.org, Andrea Arcangeli <aarcange@redhat.com>,
dave jiang <dave.jiang@intel.com>,
darrick wong <darrick.wong@oracle.com>,
vishal l verma <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 <dan.j.williams@intel.com>,
lcapitulino@redhat.com, kwolf@redhat.com,
linux-ext4@vger.kernel.org, tytso@mit.edu,
xiaoguangrong eric <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, david@fromorbit.com
Subject: Re: [Qemu-devel] security implications of caching with virtio pmem (was Re: [PATCH v3 0/5] kvm "virtio pmem" device)
Date: Tue, 5 Feb 2019 02:29:37 -0500 (EST) [thread overview]
Message-ID: <1689233487.69735950.1549351777236.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20190204170515-mutt-send-email-mst@kernel.org>
+CC [Dave Chinner], to maintain updated CC list
> > 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.
>
> 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.
>
>
> 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.
>
>
>
> 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.
>
>
> Other security implications: recent discussion seems to suggest there
> are other concerns around e.g. resource management and thus DOS
> potential. If that's so, it's a matter for a separate discussion
> as I didn't look into that in depth.
>
> Some or all of the above might be based on a misunderstanding of the
> current pmem code, the whitepaper and linux page cache in general.
> If so I apologise, do not hesitate to call out any mistakes.
>
> Thanks!
>
> --
> MST
>
>
next prev parent reply other threads:[~2019-02-05 7:29 UTC|newest]
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 ` Pankaj Gupta [this message]
2019-02-06 14:00 ` David Hildenbrand
2019-02-06 18:01 ` Michael S. Tsirkin
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 publicly 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=1689233487.69735950.1549351777236.JavaMail.zimbra@redhat.com \
--to=pagupta@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@fromorbit.com \
--cc=david@redhat.com \
--cc=hch@infradead.org \
--cc=imammedo@redhat.com \
--cc=jack@suse.cz \
--cc=jasowang@redhat.com \
--cc=jmoyer@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--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=mst@redhat.com \
--cc=nilal@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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).