Re: xend leaks/bugs/etc

[Harry Butterworth <harry@hebutterworth.freeserve.co.uk>]

On Mon, 2005-04-18 at 11:16 -0500, Hollis Blanchard wrote:
> On Mon, 2005-04-18 at 10:45 -0500, Anthony Liguori wrote:
> > Hollis Blanchard wrote:
> > 
> > >On Mon, 2005-04-18 at 10:15 -0500, Anthony Liguori wrote:
> > >  
> > >>This is a very big problem.  One very difficult issue to address is
> > >>how to deal with very hostile domains that may attempt DoS attacks by 
> > >>flooding their own console.
> > >
> > >This isn't really a xend issue. I'm not sure this *can* be addressed,
> > >and I believe other hypervisors have this problem as well.
> > >  
> > I'm not sure I agree.  Since Xen only provides shared-memory and event 
> > channels, the tools control how frequently they look at shared-memory 
> > (so a tool can throttle itself).  The only possible DoS venue should be 
> > the event channels.  The tools should simply be able to unbind from 
> > event channels that are considered hostile.
> 
> And how exactly would you distinguish between a hostile domain and a
> mission-critical-yet-chatty domain? Or would you indiscriminately drop
> console data from all overly talkative domains?
> 

The above are just quota issues. It ought to be possible to throttle
inter-domain notification to meet a quota. The quotas can be
configurable. A mission critical yet chatty domain must be configured
with a high quota and it gets to starve other less critical domains when
it wants.

The problems with the existing xend code are less subtle.  On the order
of failing to check parameters passed from domains or failing to cope
with domains that issue protocol requests out of sequence.  Basically,
as far as I can tell, the current xend code just assumes that the
communication it is handling will follow the expected good path and the
behaviour of xend if things do not go to plan is substantially
undefined.

I guess it's possible that this has all been carefully thought through
but it certainly isn't obvious from reading the code: the state machines
for handling the device channel set-up protocol are coded implicitly in
the chaining of message handling functions, it's very hard to say what
the behaviour is under receipt of erroneous or malicious sequences of
messages from front or back end domains.

Harry