WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] page ref/type count overflows

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] page ref/type count overflows
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Mon, 26 Jan 2009 13:10:45 +0000
Delivery-date: Mon, 26 Jan 2009 05:10:39 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel