[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH RFC 0/5] Grant table for console, xenstorepages



This has been looked at by others as well (I had a very similar set of
internal patches that created a pre-dom0 domain but for running the vTPM
Manager).  The trickiest part of deciding where and when to launch
xenstore is that it is required for the paravirt drivers to communicate.
So if you have any front ends, then xenstore needs to be running before
they can connect to their back ends.

Joe

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Diego Ongaro
Sent: Monday, July 14, 2008 8:42 AM
To: Derek.Murray@xxxxxxxxxxxx
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH RFC 0/5] Grant table for console,
xenstorepages

Derek Murray wrote:
> On Mon, Jul 14, 2008 at 3:37 PM, Diego Ongaro
<diego.ongaro@xxxxxxxxxx> wrote:
>> Derek Murray wrote:
>>>> I'm working on moving xenstored into a dedicated, unprivileged
domain.
>> Have you also worked on this, Derek? I wouldn't want to keep working
on
>> something you've already done...
> 
> I haven't worked on this myself, but I vaguely recall hearing of
> efforts to disaggregate XenStore - I don't think any of these are
> publicly available. Is the main aim of this work to enhance security
> or performance? If the former, how do you plan to launch the XenStore
> domain? From Dom0, or using another mechanism?

Enhancing security is one aim of this work.

I'm launching the XenStore domain using a small program in dom0 that
just makes the necessary libxc calls. I couldn't really use xend, xm, or
xenconsoled as they all depend on xenstore. (However, I ripped out the
main loop of xenconsoled so that I'd be able to get at a console.)

> My personal inclination is to enhance Xen so that the tools no longer
> run as root (a conventional Unix-based privilege separation), which
> provides a low-cost improvement in Dom0 security. This would build on
> your patches to use gntdev for console and XenStore access, and use
> modifications to gntdev that allow non-root users to map certain
> explicitly-specified grants. This would provide a route to
> disaggregating all necessarily-trusted functionality on systems that
> would benefit from it (i.e. IOMMU-equipped systems). If you'd like, we
> could discuss this approach further.

I think that approach definitely makes sense for something like the
console daemon, which I would argue should stay in dom0. On the other
hand, I don't see any technical reasons why XenStore needs to stay in
dom0, and I don't think it's such a high-cost improvement to move it
out.

-Diego

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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.