Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757500Ab2HIJzr (ORCPT ); Thu, 9 Aug 2012 05:55:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56842 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754477Ab2HIJzq (ORCPT ); Thu, 9 Aug 2012 05:55:46 -0400 Date: Thu, 9 Aug 2012 15:25:14 +0530 From: Amit Shah To: Masami Hiramatsu Cc: 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, Avi Kivity , Rusty Russell Subject: Re: [RFC PATCH 2/6] virtio/console: Add a failback for unstealable pipe buffer Message-ID: <20120809095514.GJ3280@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <502381EA.80805@hitachi.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2795 Lines: 68 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? 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/