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/
Home Products Support Community News


Re: [Xen-devel] Tiny patch for 2004 04 08 unstable tarball. arch/xen/ker

To: Adam Heath <doogie@xxxxxxxxxx>
Subject: Re: [Xen-devel] Tiny patch for 2004 04 08 unstable tarball. arch/xen/kernel/time.c
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Fri, 09 Apr 2004 10:18:31 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxxx>, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Fri, 09 Apr 2004 10:20:12 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Fri, 09 Apr 2004 03:27:56 CDT." <Pine.LNX.4.58.0404090326550.13832@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> > There's an argument for doing away with the option
> > altogether. Xen enforces the protection, so it doesn't matter
> > whether untrusted domains are compiled with
> > CONFIG_XEN_PRIVILEGED_GUEST or not. The amount of code that this
> > option compiles out is likely less than 1KB, so it's probably
> > not worth having.
> >
> > However, we should make sure that the domain hides the various
> > proc files if it has insufficient privilege from Xen, so as to
> > avoid confusing users.
> In that case, the config option should be used for that.
> If it's set, don't even bother checking whether you can do privledged ops, and
> just assume you can't; also, don't bother creating the proc files.

That's what already happens with the CONFIG option.

Also, we don't create the proc files if the domain has
insufficient privilege to be able to use
them. (e.g. /proc/xen/priv_cmd won't exist).

> If it *is* set, then you still have to check, as the instance may not have
> been given the nescessary privs.

I was just questioning whether it was worth maintaing the build
option at all. I guess it's no hassle, and serves to document the
code which wouldn't be needed for other guestos ports that aren't
intended to be used as a privileged domain.


This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
Xen-devel mailing list