|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] page ref/type count overflows
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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] page ref/type count overflows,
Jan Beulich <=
|
|
|
|
|