Re: [RFC][PATCH 0/5] Add V4V to Xen

[Tim Deegan <tim@xen.org>]

At 11:48 +0100 on 13 Jun (1339588138), Jean Guyader wrote:
> On 07/06 04:36, Tim Deegan wrote:
> > Using one ring for all clients raises the question of access control and
> > admission control -- in particular how do you avoid DoS from
> > badly-behaved clients?
> > 
> > And, given your concerns about sharing an OS with an uncooperative
> > Xenstore client, how do you handle sharing the OS with a badly behaved
> > v4v client?
> > 
> > If we _do_ need one ring with multiple writers, and therefore Xen needs
> > to arbitrate writes, there's still room for the policy-based parts
> > (controlling connection setup, for example) to live outside the
> > hypervisor, openvswitch-style.
> 
> Today the acl check in V4V (not part of the current patch serie) is
> done for every copy by Xen.

OK; can you describe roughly how it works?  Is it a whitelist of good
domains, or a blacklist of bad?  Does it just do access control or is
there rate limiting?  Can it detect and block badly-behaved clients,
or is that something you do in the server?

Have you given any thought to my second question -- if you can't rely on
the existing xenstore code, are there problems with sharing a VM with
other v4v drivers?  My intuition is that at least it would not be so
bad, since non-malicious drivers ought to be able to coexist, but I'd
like to know your opinion.

> Moving the policy control outside of Xen
> would mean that you still need to have a copy of the acls in Xen and
> the worst thing that can happen is for the copy to get out of sync.

What I meant by openvswitch-style is to have a single low-level ACL in
the hypervisor (maybe as a whitelist of known good connections) and
fault all unusual behaviour (new domain appears, &c) to the more complex
policy engine in user-space.

Really it depends on what kind of policy you want to be able to express.
If a simple yes/no whitelist is good enough (and always will be) then it
may as well live in the hypervisor and we can skip the 'defer to
userspace' part.

> What do you think would be the next step going forward?

Hopefully, to get some feedback from other people (specifically Ian, Ian
and Stefano but anyone else too!) and decide what, if anything, ought to
be changed about the design.

My feedback has mostly been about the hypervisor side of things -- I'm
sure the tools maintainers have some ideas about how this should be
merged with libvchan, to avoid having two separate comms interfaces.

Cheers,

Tim.