From: Paolo Bonzini <pbonzini@redhat.com>
To: George Dunlap <dunlapg@umich.edu>
Cc: Xen-devel@lists.xensource.com,
James Harper <james.harper@bendigoit.com.au>,
Jonathan Tripathy <jonnyt@abpni.co.uk>
Subject: Re: Security Implications of letting customers use theirown kernel
Date: Thu, 16 Dec 2010 14:05:01 +0100 [thread overview]
Message-ID: <4D0A0E7D.6090503@redhat.com> (raw)
In-Reply-To: <AANLkTinb0upcNB-0o28cpGrKkUtL5LObpH94f7hvmzOA@mail.gmail.com>
On 12/16/2010 01:03 PM, George Dunlap wrote:
> And as James H. said, buggy DomU drivers do occasionally crash dom0:
> and if untrusted code can accidentally crash privileged code, it's
> often the case that a well-crafted exploit can use the same bug to
> gain control of the privileged code.
I wouldn't be so negative. :)
I've definitely seen crashes of the hypervisor, but all of them were
assertion failures rather than say a null-pointer dereference. I've
also seen denial of service bugs on the dom0 kernel which exploited bugs
in the backend drivers. Maybe I'm "young" as a Xen developer (less than
2 years) but the core Xen code always seemed very robust to me.
I would hence be slightly worried of crashes and even denial of service
on the management tools, but not so much of privilege escalation. (A
couple such bugs were found a few years ago by Joanna Rutkowska's team,
but are quite rare).
That said, I wouldn't be _more_ worried if I let customers use their own
kernel, since they may anyway be able to use their own kernel modules if
they have root access to the VM, so there's almost nothing that they
couldn't already do before.
There is another bug that is specific of a VM environment is where
hypervisor bugs allow a malicious user in the guest to gain access to
ring0 in the guest (see for example CVE-2010-0419, though this one is
for KVM). These are the ones that would worry me the most.
Paolo
prev parent reply other threads:[~2010-12-16 13:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-15 12:26 Security Implications of letting customers use their own kernel Jonathan Tripathy
2010-12-16 3:51 ` Security Implications of letting customers use theirown kernel James Harper
2010-12-16 12:03 ` George Dunlap
2010-12-16 12:06 ` Jonathan Tripathy
2010-12-16 13:05 ` Paolo Bonzini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D0A0E7D.6090503@redhat.com \
--to=pbonzini@redhat.com \
--cc=Xen-devel@lists.xensource.com \
--cc=dunlapg@umich.edu \
--cc=james.harper@bendigoit.com.au \
--cc=jonnyt@abpni.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).