Re: [Xen-devel] [PATCH 0/3] domUloader

On Tue, 17 Jan 2006, Kurt Garloff wrote:

> 2. The filesystem in the domU could be prepared such that the kernel
>    trips over a bug in its filesystem code.
>    The same can happen if you read the FS with a userspace library
>    of course, but the effects would be less bad -- at least if you
>    would do it with non-root euid.
>    The downside is that need to use a secondary source for filesystem
>    code, which needs to be maintained and kept in sync, audited, ...
>    And you are limited to the filesystems where you have userspace
>    libraries for.
>    In a paranoid scenario, you would not load any data from the domU
>    filesystem in any way :-) But I can see why you would choose
>    pygrub over domUloader in a sensitive environment, where you
>    can't trust the domU admins. Point taken.
>    I still think that in many use scenarios, you would be perfectly
>    fine with domUloader.

Have a special kernel that is used just for this, then boot a temporary domU,
using this special kernel, read the data you need from the filesystem, then
shut it down.


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

<Prev in Thread]

Current Thread

[Next in Thread>

Previous by Date:

Re: [Xen-devel] adding device driver kernel module for xen/linux, Fajar A. Nugraha

Next by Date:

[Xen-devel] [PATCH] VTPM_Tools, Scarlata, Vincent R

Previous by Thread:

Re: [Xen-devel] [PATCH 0/3] domUloader, Kurt Garloff

Next by Thread:

Re: [Xen-devel] [PATCH 0/3] domUloader, Kurt Garloff

Indexes:

[Date] [Thread] [Top] [All Lists]