xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

      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).