From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:38228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gt6AL-0007d6-Df for qemu-devel@nongnu.org; Mon, 11 Feb 2019 02:38:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gt6AJ-0003Dj-Aq for qemu-devel@nongnu.org; Mon, 11 Feb 2019 02:38:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56578) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gt6AH-0003Bn-DY for qemu-devel@nongnu.org; Mon, 11 Feb 2019 02:38:05 -0500 Date: Mon, 11 Feb 2019 02:29:46 -0500 (EST) From: Pankaj Gupta Message-ID: <888328358.132676.1549870186945.JavaMail.zimbra@redhat.com> In-Reply-To: <20190204170515-mutt-send-email-mst@kernel.org> References: <20190109144736.17452-1-pagupta@redhat.com> <20190204170515-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] security implications of caching with virtio pmem (was Re: [PATCH v3 0/5] kvm "virtio pmem" device) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , dchinner@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 , zwisler@kernel.org, Andrea Arcangeli , dave jiang , darrick wong , vishal l verma , 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 , lcapitulino@redhat.com, kwolf@redhat.com, linux-ext4@vger.kernel.org, tytso@mit.edu, xiaoguangrong eric , rjw@rjwysocki.net, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, pbonzini@redhat.com Hi Michael, Thanks for looking into this and summarizing in detail. > > 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. I agree similar to any guest VM(without virtio-pmem) or any host userspace process, virtio-pmem may also have some security implications. We need to document these in virtio-pmem host device specification and in qemu code. This is to make sure while creating virtio-pmem device, we are aware of these implications and create/use host side device backing file accordingly as per the use-case described by David here [1]. I will document these in next version of my patch series. Hello Dave, Are we okay with this? Thank you everyone for the discussion. [1] https://marc.info/?l=linux-kernel&m=154946989419403&w=2 Best regards, Pankaj