[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device
From: |
Pankaj Gupta |
Subject: |
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device |
Date: |
Fri, 11 Jan 2019 02:45:04 -0500 (EST) |
>
> 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.
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.
>
> 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.....
If I am following correctly the discussions in MM thread.
Important steps to mitigate this:
* Avoid running mincore in privilege mode: to safeguard page evict state of any
page cache page.
* tweaking RWF_NOWAIT
I think if we secure ways to find current state(cached/evicted) of a page in
host,
we should be able to mitigate the impact for any page cache page access attack
including virtio-pmem.
Thanks,
Pankaj
- Re: [Qemu-devel] [PATCH v3 5/5] xfs: disable map_sync for virtio pmem, (continued)
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Dave Chinner, 2019/01/09
- Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Rik van Riel, 2019/01/10
- Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Jan Kara, 2019/01/10
- Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Pankaj Gupta, 2019/01/12
- Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Dan Williams, 2019/01/12
- Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Pankaj Gupta, 2019/01/12
- Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Jan Kara, 2019/01/14
- Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Pankaj Gupta, 2019/01/14
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device,
Pankaj Gupta <=
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Dave Chinner, 2019/01/13
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Matthew Wilcox, 2019/01/13
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Dave Chinner, 2019/01/13
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Pankaj Gupta, 2019/01/14
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Dave Chinner, 2019/01/14
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Dan Williams, 2019/01/14
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Dave Chinner, 2019/01/14
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Michael S. Tsirkin, 2019/01/14
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Pankaj Gupta, 2019/01/15
Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device, Pankaj Gupta, 2019/01/15