Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757639Ab2HIKPV (ORCPT ); Thu, 9 Aug 2012 06:15:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23196 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751477Ab2HIKPU (ORCPT ); Thu, 9 Aug 2012 06:15:20 -0400 Date: Thu, 9 Aug 2012 15:44:47 +0530 From: Amit Shah To: Avi Kivity Cc: Masami Hiramatsu , Yoshihiro YUNOMAE , linux-kernel@vger.kernel.org, Anthony Liguori , Arnd Bergmann , Borislav Petkov , "Franch Ch. Eigler" , Frederic Weisbecker , Greg Kroah-Hartman , Herbert Xu , Ingo Molnar , Mathieu Desnoyers , Steven Rostedt , virtualization@lists.linux-foundation.org, qemu-devel@nongnu.org, yrl.pp-manager.tt@hitachi.com, Rusty Russell Subject: Re: [RFC PATCH 2/6] virtio/console: Add a failback for unstealable pipe buffer Message-ID: <20120809101447.GM3280@amit.redhat.com> References: <20120724023657.6600.52706.stgit@ltc189.sdl.hitachi.co.jp> <20120724023718.6600.68836.stgit@ltc189.sdl.hitachi.co.jp> <20120809090312.GH3280@amit.redhat.com> <502381EA.80805@hitachi.com> <20120809095514.GJ3280@amit.redhat.com> <502389B5.4020506@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <502389B5.4020506@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3223 Lines: 74 On (Thu) 09 Aug 2012 [12:58:13], Avi Kivity wrote: > On 08/09/2012 12:55 PM, Amit Shah wrote: > > On (Thu) 09 Aug 2012 [18:24:58], Masami Hiramatsu wrote: > >> (2012/08/09 18:03), Amit Shah wrote: > >> > On (Tue) 24 Jul 2012 [11:37:18], Yoshihiro YUNOMAE wrote: > >> >> From: Masami Hiramatsu > >> >> > >> >> Add a failback memcpy path for unstealable pipe buffer. > >> >> If buf->ops->steal() fails, virtio-serial tries to > >> >> copy the page contents to an allocated page, instead > >> >> of just failing splice(). > >> >> > >> >> Signed-off-by: Masami Hiramatsu > >> >> Cc: Amit Shah > >> >> Cc: Arnd Bergmann > >> >> Cc: Greg Kroah-Hartman > >> >> --- > >> >> > >> >> drivers/char/virtio_console.c | 28 +++++++++++++++++++++++++--- > >> >> 1 files changed, 25 insertions(+), 3 deletions(-) > >> >> > >> >> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c > >> >> index fe31b2f..911cb3e 100644 > >> >> --- a/drivers/char/virtio_console.c > >> >> +++ b/drivers/char/virtio_console.c > >> >> @@ -794,7 +794,7 @@ static int pipe_to_sg(struct pipe_inode_info *pipe, struct pipe_buffer *buf, > >> >> struct splice_desc *sd) > >> >> { > >> >> struct sg_list *sgl = sd->u.data; > >> >> - unsigned int len = 0; > >> >> + unsigned int offset, len; > >> >> > >> >> if (sgl->n == MAX_SPLICE_PAGES) > >> >> return 0; > >> >> @@ -807,9 +807,31 @@ static int pipe_to_sg(struct pipe_inode_info *pipe, struct pipe_buffer *buf, > >> >> > >> >> len = min(buf->len, sd->len); > >> >> sg_set_page(&(sgl->sg[sgl->n]), buf->page, len, buf->offset); > >> >> - sgl->n++; > >> >> - sgl->len += len; > >> >> + } else { > >> >> + /* Failback to copying a page */ > >> >> + struct page *page = alloc_page(GFP_KERNEL); > >> > > >> > I prefer zeroing out the page. If there's not enough data to be > >> > filled in the page, the remaining data can be leaked to the host. > >> > >> Yeah, it is really easy to fix that. > >> But out of curiosity, would that be really a problem? > >> I guess that host can access any guest page if need. If that > >> is right, is that really insecure to leak randomly allocated > >> unused page to the host? > > > > I'm not sure if there is a way to really attack, but just something I > > had thought about: the host kernel can access any guest page, that's > > not something we can prevent. > > > > However, if qemu is restricted from accessing guest pages, and the > > guest shares this page with qemu for r/w purposes via the virtio > > channel, a qemu exploit can expose guest data to host userspace. > > > > I agree this is completely theoretical; can someone else with more > > insight confirm or deny my apprehensions? > > qemu can read and write any guest page (for the guest it controls). OK, thanks for confirming -- no need to change this patch, then. Amit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/