|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [ANNOUNCE] xen ocaml tools
I've cleaned up the attack code (and added copy right info), Makefile, and
README a bit for the attack. Please find the revised version attached.
Patrick
Patrick Colp wrote:
Vincent Hanquez wrote:
Patrick Colp wrote:
I'm really excited to see somebody else working on an OCaml XenStore!
I was wondering if you could tell me what the difference are between
this implementation and the one I recently released to the community?
this is a bit hard to tell without testing your version.
but i think the main difference is the way we handle transactions,
which should provide a stable average time to commit transactions when
having lots of xenstore traffic from guests.
I think you're thinking of my initial release last year. The version I
released a few months ago also has an in-memory store and greatly
improved transactions. It was motivated by the need to survive things
like DoS attacks.
I wrote a little attack program (in OCaml) which runs from any DomU and
brought the original xenstored to its knees. With the attack going, it's
impossible to bring a new domain up -- it just hangs forever attempting
to bring it up. Basically, the attack just hammers xenstored with
micro-transactions. With the original transaction system, which allows
the first committing transaction in a generation to win, long
transactions could never complete. I implemented transactions that would
enable all concurrent but non-conflicting transactions to commit. This
made my version of xenstored resilient to the attack.
I played around with this with your version too, but found that, while
it would not hang forever while attempting to load a domain, it would
instead die after a few seconds with the following error:
Error: (2, 'No such file or directory')
I tried with with the eagain mode thing (random dropping of 1/3 of all
transactions) both enabled and disabled, but it had the same effect
(except that with the mode enabled, 1/3 of all transactions would fail
regardless of if they should or not).
I've been reading over your code and noticed that you seem to have a
mini-implementation of libxc. I was wondering why you chose to do this
over using the pre-existing libxenctrl? Does this make the final
executable smaller?
Patrick
------------------------------------------------------------------------
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
attack.tar.gz
Description: GNU Zip compressed data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|