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

[Wei Liu <wei.liu2@citrix.com>]

On Tue, Sep 19, 2017 at 12:04:42PM +0100, Ian Jackson wrote:
> 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).
> 

Ah, I know where I got myself confused.

You can have my Ack on this patch.

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