lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 09 Aug 2012 12:58:13 +0300 From: Avi Kivity <avi@...hat.com> To: Amit Shah <amit.shah@...hat.com> CC: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>, Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>, linux-kernel@...r.kernel.org, Anthony Liguori <anthony@...emonkey.ws>, Arnd Bergmann <arnd@...db.de>, Borislav Petkov <bp@...64.org>, "Franch Ch. Eigler" <fche@...hat.com>, Frederic Weisbecker <fweisbec@...il.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Herbert Xu <herbert@...dor.hengli.com.au>, Ingo Molnar <mingo@...hat.com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Steven Rostedt <rostedt@...dmis.org>, virtualization@...ts.linux-foundation.org, qemu-devel@...gnu.org, yrl.pp-manager.tt@...achi.com, Rusty Russell <rusty@...tcorp.com.au> Subject: Re: [RFC PATCH 2/6] virtio/console: Add a failback for unstealable pipe buffer 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 <masami.hiramatsu.pt@...achi.com> >> >> >> >> 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 <masami.hiramatsu.pt@...achi.com> >> >> Cc: Amit Shah <amit.shah@...hat.com> >> >> Cc: Arnd Bergmann <arnd@...db.de> >> >> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org> >> >> --- >> >> >> >> 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). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists