From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEKEu-0001Cr-0P for qemu-devel@nongnu.org; Wed, 19 Sep 2012 09:22:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEKEm-0006Qu-EQ for qemu-devel@nongnu.org; Wed, 19 Sep 2012 09:22:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEKEm-0006Qb-6K for qemu-devel@nongnu.org; Wed, 19 Sep 2012 09:22:44 -0400 Date: Wed, 19 Sep 2012 10:23:26 -0300 From: Luiz Capitulino Message-ID: <20120919102326.54f7a921@doriath.home> In-Reply-To: <20120919.112651.385607604.d.hatayama@jp.fujitsu.com> References: <87obl36nlx.fsf@codemonkey.ws> <20120918211845.5f4344b9@doriath.home> <505928C8.9060801@cn.fujitsu.com> <20120919.112651.385607604.d.hatayama@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qmp: dump-guest-memory: -p option has issues, fix it or drop it? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: HATAYAMA Daisuke Cc: jan.kiszka@siemens.com, mtosatti@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, anthony@codemonkey.ws, eblake@redhat.com On Wed, 19 Sep 2012 11:26:51 +0900 (JST) HATAYAMA Daisuke wrote: > From: Wen Congyang > Subject: Re: [Qemu-devel] qmp: dump-guest-memory: -p option has issues, fix it or drop it? > Date: Wed, 19 Sep 2012 10:07:04 +0800 > > > At 09/19/2012 08:18 AM, Luiz Capitulino Wrote: > >> On Tue, 18 Sep 2012 16:13:30 -0500 > >> Anthony Liguori wrote: > >> > >>> Markus Armbruster writes: > >>> > >>>> Jan Kiszka writes: > >>>> > >>>>>>>>> * The issues discussed in this email plus the fact that the guest > >>>>>>>>> memory may be corrupted, and the guest may be in real-mode even > >>>>>>>>> when paging is enabled > >>>>>>>>> > >>>>>>>> > >>>>>>>> Yes, there are some limitations with this option. Jan said that he > >>>>>>>> always use gdb to deal with vmcore, so he needs such information. > >>>>>>> > >>>>>>> The point is to overcome the focus on Linux-only dump processing tools. > >>>>>> > >>>>>> While I don't care for supporting alternate dump processing tools > >>>>>> myself, I certainly don't mind supporting them, as long as the code > >>>>>> satisfies basic safety and reliability requirements. > >>>>>> > >>>>>> This code doesn't, as far as I can tell. > >>>>> > >>>>> It works, thought not under all circumstances. > >>>> > >>>> I don't doubt it works often enough to be useful to somebody. But basic > >>>> safety and reliability requirements are a bit more than that. They > >>>> include "don't explode in ways a reasonable user can't be expected to > >>>> foresee". I don't think a reasonable user can be expected to see that > >>>> -p is safe only for trusted guests. > >>> > >>> We shipped the API, we're not removing it. Our compatibility isn't > >>> "whatever libvirt is currently using". > >>> > >>> It's perfectly reasonable to ask to document the behavior of the > >>> method. It's also a trivial patch to qapi-schema.json. > >> > >> I feel that documenting it is not enough. It would be fine to do that > >> if the worst case was a bad dump file, but the worst case as the > >> code stands right now will affect the host. > >> > >>> It's unreasonable to ask for an interface to be removed just because it > >>> could be misused when it has a legimitate use-case. > >> > >> The point is not that it can be misused. The issue we're concerned about > >> is that a malicious guest could cause qemu to allocate dozens of > >> gigabytes of RAM. > > > > Hmm, I guess the malicious guest's page table provides wrong information. > > We allocate memory to store memory mapping. Each memory mapping needs > > less than 40 bytes memory. The num of memory mapping is less than > > (2^48) / (2^12) = 2^36. And 2^36 * 40 = 64G * 40, too many memory.... > > > > What about this: > > 1. if the num of memory mapping > 100000, we only store 100000 memory > > mappings. > > > > 2. The memory mapping which has smaller virtual address will be dropped? > > > > In this case, the memory we need is less than 10MB. So we will not allocate > > too many memory. The problem of artificially limiting it is that we can reach the limit in "legal" usage (ie. a very large machine). > How about dropping making a whole list of memory maps at the same > time, and how about rewriting the code so that it always has at most > one memory mapping by merging virtually consequtive chunks? If > possible, only 40 bytes is needed. It already merges contiguous addresses and addresses that fall in the same range. It can also skip addresses due to a few reasons (I/O page, not present page, etc), which makes the problem very unlikely in practice. Our concern is with guests intentionally trying to make qemu allocate more memory.