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

[Jean Guyader <jean.guyader@xxxxxxxxx>]

On 13 June 2012 12:44, Tim Deegan <tim@xxxxxxx> wrote:
> 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?
>

In xen we keep of list of simple acls. Here is the usage of the userspace
tools that controls it. This is a straight forward implementation of the rule
API.

Usage: viptables command [rule]
Commands :
  --append      -A                      Append rule
  --insert      -I <n>                  Insert rule before rule <n>
  --list        -L                      List rules
  --delete      -D[<n>]                 Delete rule <n> or the following rule
  --flush       -F                      Flush rules
  --help        -h                      Help
Rule options:
  --dom-in      -d <n>                  Client domid
  --dom-out     -e <n>                  Server domid
  --port-in     -p <n>                  Client port
  --port-out    -q <n>                  Server port
  --jump        -j {ACCEPT|REJECT}      What to do


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

Are you talking about having different version of V4V driver running
in the same VM?
I don't think that is a problem they both interact with Xen via
hypercall directly so
if they follow the v4v hypercall interface it's all fine.

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

Yes sure.

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

Ok. Thanks for your feedback.

Jean

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