WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] xend leaks/bugs/etc

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel