From: Diego Ongaro <diego.ongaro@citrix.com>
To: Derek.Murray@cl.cam.ac.uk
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH RFC 0/5] Grant table for console, xenstore pages
Date: Mon, 14 Jul 2008 16:42:28 +0100 [thread overview]
Message-ID: <487B73E4.6020600@citrix.com> (raw)
In-Reply-To: <617dbaa80807140755oefd307hbd60c4551b6a076d@mail.gmail.com>
Derek Murray wrote:
> On Mon, Jul 14, 2008 at 3:37 PM, Diego Ongaro <diego.ongaro@citrix.com> 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
next prev parent reply other threads:[~2008-07-14 15:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-11 19:12 [PATCH RFC 0/5] Grant table for console, xenstore pages Diego Ongaro
2008-07-11 19:14 ` [PATCH RFC 1/5] " Diego Ongaro
2008-07-11 19:15 ` [PATCH RFC 2/5] " Diego Ongaro
2008-07-11 19:16 ` [PATCH RFC 3/5] " Diego Ongaro
2008-07-11 19:17 ` [PATCH RFC 4/5] " Diego Ongaro
2008-07-11 19:17 ` [PATCH RFC 5/5] " Diego Ongaro
2008-07-12 18:34 ` [PATCH RFC 0/5] " Derek Murray
2008-07-12 18:42 ` Samuel Thibault
2008-07-14 14:37 ` Diego Ongaro
2008-07-14 14:55 ` Derek Murray
2008-07-14 15:42 ` Diego Ongaro [this message]
2008-07-14 16:50 ` [PATCH RFC 0/5] Grant table for console, xenstorepages Cihula, Joseph
2008-07-14 17:04 ` Diego Ongaro
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=487B73E4.6020600@citrix.com \
--to=diego.ongaro@citrix.com \
--cc=Derek.Murray@cl.cam.ac.uk \
--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.