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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

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).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel