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

Re: [Xen-devel] [PATCH 03/22] xentoolcore, _restrict_all: Introduce new library and implementation

Wei Liu writes ("Re: [PATCH 03/22] xentoolcore, _restrict_all: Introduce new 
library and implementation"):
> The impression I get from the name and parameter from this API is that
> the following use case is allowed: a device model serving multiple
> domains.

Such a device model is obviously, by necessity, unrestricted.

> The device model will open two sets of handlers of various
> libraries. The device model will call restrict_all(domid) to restrict
> its own privileges on certain domid when it sees fit.

After it has restricted its privileges to domid A, it is no longer
permitted to do things to domid B.  Attempting to call restrict_all(B)
will fail.

> Without filtering, the callbacks are called for all the domains at the
> same time. The code as-is, when resctrict_all(dom1) is called, makes
> privileges on dom2 are also dropped sometimes -- imagine a xenstore
> callback registered for dom2 is called, which makes the connection
> unusable for dom2.
> If the aforementioned use case is not anticipated, I think we shouldn't
> accept domid parameter for the resctrict_all function.

But the domid is precisely the scope of the intended restriction.
After making the call, the malign influence of the calling process is
limited to the specified domid (at least, insofar as the malign
influence is exercised via already-open Xen library handles).


Xen-devel mailing list



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