From: Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org> To: Pankaj Gupta <pagupta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: jack-AlSwsSmVLrQ@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org, jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org, virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, adilger kernel <adilger.kernel-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>, zwisler-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, darrick wong <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>, mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, nilal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, riel-ebMLmSuQjDVBDgjK7y7TUQ@public.gmane.org, stefanha-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, imammedo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, lcapitulino-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, kwolf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tytso-3s7WtUTddSA@public.gmane.org, xiaoguangrong eric <xiaoguangrong.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org Subject: Re: [PATCH v3 0/5] kvm "virtio pmem" device Date: Mon, 14 Jan 2019 10:29:02 +1100 [thread overview] Message-ID: <20190113232902.GD4205@dastard> (raw) In-Reply-To: <1326478078.61913951.1547192704870.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> On Fri, Jan 11, 2019 at 02:45:04AM -0500, Pankaj Gupta 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). > > Not sure how? this is similar to mmapping virtual memory by any userspace > process. Any host userspace process can do such attack on host page cache > using mincore & mmap shared file. Mincore is for monitoring, not cached eviction. And it's not required to observe cache residency, either. That's a wide open field containing an uncountable number of moles... > But i don't think guest can do this alone. For virtio-pmem usecase > guest won't be using page cache so timing attack from only guest > side is not possible unless host userspace can run checks on page > cache eviction state using mincore etc. As rightly described by > Rik, guest will only access its own page cache pages and if guest > page cache is managed directly by host, this saves alot of effort > for guest in transferring guest state of page cache. 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.e. it's something we need to be aware of and really careful about enabling infrastructure that /will/ be abused if guests can find a way to influence the host side cache residency. Cheers, Dave. -- Dave Chinner david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com> To: Pankaj Gupta <pagupta@redhat.com> Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, qemu-devel@nongnu.org, linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-acpi@vger.kernel.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, jack@suse.cz, stefanha@redhat.com, dan j williams <dan.j.williams@intel.com>, riel@surriel.com, nilal@redhat.com, kwolf@redhat.com, pbonzini@redhat.com, zwisler@kernel.org, vishal l verma <vishal.l.verma@intel.com>, dave jiang <dave.jiang@intel.com>, david@redhat.com, jmoyer@redhat.com, xiaoguangrong eric <xiaoguangrong.eric@gmail.com>, hch@infradead.org, mst@redhat.com, jasowang@redhat.com, lcapitulino@redhat.com, imammedo@redhat.com, eblake@redhat.com, willy@infradead.org, tytso@mit.edu, adilger kernel <adilger.kernel@dilger.ca>, darrick wong <darrick.wong@oracle.com>, rjw@rjwysocki.net Subject: Re: [PATCH v3 0/5] kvm "virtio pmem" device Date: Mon, 14 Jan 2019 10:29:02 +1100 [thread overview] Message-ID: <20190113232902.GD4205@dastard> (raw) Message-ID: <20190113232902.-Q8wo_0B6u96BzVxfgEFveV9VRQhASCq_GrclGFcWfY@z> (raw) In-Reply-To: <1326478078.61913951.1547192704870.JavaMail.zimbra@redhat.com> On Fri, Jan 11, 2019 at 02:45:04AM -0500, Pankaj Gupta 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). > > Not sure how? this is similar to mmapping virtual memory by any userspace > process. Any host userspace process can do such attack on host page cache > using mincore & mmap shared file. Mincore is for monitoring, not cached eviction. And it's not required to observe cache residency, either. That's a wide open field containing an uncountable number of moles... > But i don't think guest can do this alone. For virtio-pmem usecase > guest won't be using page cache so timing attack from only guest > side is not possible unless host userspace can run checks on page > cache eviction state using mincore etc. As rightly described by > Rik, guest will only access its own page cache pages and if guest > page cache is managed directly by host, this saves alot of effort > for guest in transferring guest state of page cache. 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.e. it's something we need to be aware of and really careful about enabling infrastructure that /will/ be abused if guests can find a way to influence the host side cache residency. Cheers, Dave. -- Dave Chinner david@fromorbit.com
next prev parent reply other threads:[~2019-01-13 23:29 UTC|newest] Thread overview: 62+ 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 [this message] 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 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 -- strict thread matches above, loose matches on Subject: below -- 2019-01-09 13:50 [PATCH v3 0/5] kvm "virtio pmem" device Pankaj Gupta
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=20190113232902.GD4205@dastard \ --to=david-fqsqvqoi3ljby3ivrkzq2a@public.gmane.org \ --cc=adilger.kernel-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org \ --cc=darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \ --cc=david-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \ --cc=imammedo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=jack-AlSwsSmVLrQ@public.gmane.org \ --cc=jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=kwolf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=lcapitulino-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org \ --cc=linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=nilal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=pagupta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org \ --cc=riel-ebMLmSuQjDVBDgjK7y7TUQ@public.gmane.org \ --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \ --cc=stefanha-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=tytso-3s7WtUTddSA@public.gmane.org \ --cc=virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \ --cc=xiaoguangrong.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=zwisler-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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: linkBe 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).