All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <jbeulich@novell.com>
To: xen-devel@lists.xensource.com
Subject: page ref/type count overflows
Date: Mon, 26 Jan 2009 13:10:45 +0000	[thread overview]
Message-ID: <497DC465.76E4.0078.0@novell.com> (raw)

With pretty trivial user mode programs being able to crash the kernel due to
the ref counter widths in Xen being more narrow than in Linux, I started an
attempt to put together a kernel side fix. While addressing the plain
hypercalls is pretty strait forward, dealing with multicalls (both when using
them for lazy mmu mode batching and when explicitly using them in e.g.
netback - the backends are susceptible to this too since a malicious guest
could pass grant references to pages that cannot have additional
references obtained) isn't. I'm therefore trying to find alternatives,
preferably ones mostly transparent to the kernel.

The way I was intending to address this on the kernel side in the general
accessors was to re-issue failed hypercalls (or page table writes) with
_PAGE_PRESENT replaced by _PAGE_PROTNONE, thus converting (non-
recoverable) kernel mode faults (under the right circumstances bringing
down the whole kernel) into user mode faults. In order to avoid the
complications of handling failed multicall elements I'm now considering to
add a mechanism for the kernel to tell Xen to
- automatically do a fallback operation like this at least on failed L1 table
writes
- continue handling mmu updates when one failed (at least in the case
where the guest obviously is not prepared to pick up the pieces, i.e. when
the 'pdone' argument is NULL, or alternatively by [dynamically] altering
the meaning of that pointer so that it could point to a bitmap).

The backend drivers in my opinion have no alternative to getting taught
to do full error checking in order to avoid the respective DomU-induced
problems.

Thanks for any thoughts or opinions,
Jan

             reply	other threads:[~2009-01-26 13:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-26 13:10 Jan Beulich [this message]
2009-01-26 13:33 ` page ref/type count overflows Keir Fraser
2009-01-26 13:51   ` Keir Fraser
2009-01-26 14:10   ` Jan Beulich
2009-01-26 14:19     ` Keir Fraser
2009-01-26 14:38       ` Jan Beulich
2009-01-26 14:54         ` Keir Fraser
2009-01-26 16:15           ` Jan Beulich
2009-01-26 16:30             ` Keir Fraser
2009-01-27  9:34               ` Tim Deegan
2009-01-26 17:01           ` Keir Fraser
2009-01-27 10:16             ` Jan Beulich
2009-01-27 10:24               ` Keir Fraser
2009-01-27 11:22                 ` Keir Fraser
2009-01-27 15:38                   ` Keir Fraser
2009-01-27 15:49                     ` Jan Beulich
2009-01-27 16:03                       ` Keir Fraser
2009-01-29  8:34                 ` Jan Beulich
2009-01-29  8:45                   ` Keir Fraser
2009-01-29 10:54                     ` Jan Beulich
2009-01-29 11:07                       ` Tim Deegan
2009-01-29 11:26                         ` Keir Fraser
2009-01-29 14:04                       ` Gianluca Guida
2009-01-29 10:12                   ` Tim Deegan
2009-01-29 10:57                     ` Jan Beulich

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=497DC465.76E4.0078.0@novell.com \
    --to=jbeulich@novell.com \
    --cc=xen-devel@lists.xensource.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.