Re: [Xen-devel] [BUNDLE] Testing a simpler inter-domain transport

[Daniel Veillard <veillard@xxxxxxxxxx>]

On Sun, Feb 12, 2006 at 03:39:01PM -0800, King, Steven R wrote:
> > Note that like a real LAN, one badly behaved partition
> > can block communication for the others they share the lan with... 
> 
> Shared page LAN is much less secure than a real LAN.  Any domain
> attached to the shared page, i.e. in the LAN, can modify any frame "in
> flight" on the page.  Recipients have no confidence that the received
> frame is actually what the sender sent.

  I don't see why this would have to be the case, it should be
possible to allow only read access to pages containing packets
sent from other domains (at the expense of a bit more physical
memory being used for the service).
  Concerning host blocking communications:
    - blocking on burst write could be detected, the sender
      set of pages are full, it's a FIFO mechanism with counters
    - blocking on non-read is more problematic, but it's IMHO
      very similar to the already very well analyzed problem
      of detecting failing nodes (and partitions) in distributed
      systems. However being on the same physical machine should
      simplify handling of those case quite a bit.
(note that with only 2 domains you can't distinguish the two cases
 but if you have a garanteed well behaved node on Domain-0 you 
 should be able to always distinguish them).

  It would probably require significant code changes from an
optimistic implementation of the inter-domain transport but I don't
see why this could not be done. Sounds like it would target a relatively
different set of use case than the optimistic one, and maybe the 
cost isn't worth the protection this would bring in that context.

  Or did I missed something ?

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

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