From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44954) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qr13X-0000TA-8f for qemu-devel@nongnu.org; Wed, 10 Aug 2011 01:10:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qr13S-0006XN-MN for qemu-devel@nongnu.org; Wed, 10 Aug 2011 01:10:15 -0400 Received: from ozlabs.org ([203.10.76.45]:37824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qr13S-0006XB-8J for qemu-devel@nongnu.org; Wed, 10 Aug 2011 01:10:10 -0400 Date: Wed, 10 Aug 2011 15:10:02 +1000 From: David Gibson Message-ID: <20110810051002.GM23511@yookeroo.fritz.box> References: <1312516970-26606-1-git-send-email-david@gibson.dropbear.id.au> <4E3B8ACA.7080104@web.de> <20110805153053.GA15083@amt.cnet> <20110808060328.GB20120@yookeroo.fritz.box> <4E3F9D29.2000708@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E3F9D29.2000708@redhat.com> Subject: Re: [Qemu-devel] [PATCH] Permit -mem-path without sync mmu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: kvm , Marcelo Tosatti , qemu-devel@nongnu.org, agraf@suse.de, Paul Mackerras , Jan Kiszka On Mon, Aug 08, 2011 at 11:24:09AM +0300, Avi Kivity wrote: > On 08/08/2011 09:03 AM, David Gibson wrote: > >Second, if userspace qemu passing hugepages to kvm can cause (host) > >kernel memory corruption, that is clearly a host kernel bug. So am I > >correct in thinking this is basically just a safety feature if qemu is > >run on a buggy kernel. > > Seems so, yes. 2.6.2[456] are exploitable. We only found out after > these were all released. > > >Presumably this bug was corrected at some > >point? Is the presence of the SYNC_MMU feature just being used as a > >proxy for "is this kernel recent enough to have the corruption bug > >fixed"? > > SYNC_MMU actually fixes the bug. Ah, so SYNC_MMU fixed the bug on x86, and all the other archs without SYNC_MMU were left with a serious memory corruption bug, under a userspace bandaid. Thanks for that. As I understand the bug that causes the problem, it's because removing all the hugepage VMAs from userspace will cause the inode (and therefore address_space) for the hugepage file to be freed, but not the pages (because another ref is held by kvm). Then when kvm releases the pages, the address_space will be touched after free from free_huge_page(). This would seem to be a genuine bug in the hugepage code, which has just been hidden by SYNC_MMU. It should be quite easy to fix - the mapping is only stored in the struct page to get to the hugetlbfs superblock, so we could just store a direct superblock pointer instead, and bump it's refcount when we put that in the page private pointer. But then I'm not sure how qemu would detect that it's on a kernel where the bug is fixed and allow -mem-path to be used again. Any ideas? -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson