From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH (V9) 0/2] Add V4V to Xen Date: Fri, 31 May 2013 11:21:53 +0100 Message-ID: <51A879C1.3090708@citrix.com> References: <1369770211-4509-1-git-send-email-ross.philipson@citrix.com> <1369915658.13087.91.camel@zakaz.uk.xensource.com> <51A77964.6000500@citrix.com> <51A8505A.8030706@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51A8505A.8030706@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vincent Hanquez Cc: Ian Campbell , Ross Philipson , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 31/05/13 08:25, Vincent Hanquez wrote: > On 05/30/2013 05:08 PM, David Vrabel wrote: >> On 30/05/13 13:07, Ian Campbell wrote: >>> No patch to docs/... at all? The hypercall interface docs have improved >>> (although they still aren't great IMHO) but what's really needed is an >>> overview of the design and a "how do I actually use this" type thing. >> I agree. I'm looking at inter-domain communication mechanisms for use >> in XenServer and it's not obvious how to use v4v securely. >> >> e.g., when a previously trusted domain (A) is compromised it may spam a >> domain (B) with messages in a DoS attack. The per source domain/port >> receive rings help here as the domain A will not be able to block B from >> receiving traffic from other domains. > It's really up to the guest to take active measure to prevent this to > happens. > B have multiple ways to handle this scenario: > > * unregister his ring: A can't communicate with B anymore > * throttle his ring processing: if B doens't process his ring, > eventually the ring is full > and A can't send any more spam. These require the use of per-sender rings. > * use stream message type, which has the same semantic to tcp > (LISTENING/CONNECTING/CONNECTED/..), where a stream need to be connected > before data is processed. You would still need to handle connection request spam. > There's also the v4v firewall where connection can be blocked. > I'm not sure at the moment that a guest can set anything in it itself, > but if not > i think it would be a good idea for a guest to proactively set blocking > rules for > ring it owns. At the moment it looks like only privileged guest can add/modify v4vtable rules. >> But how are these per-connection rings created? This seems to require >> out-of-band signaling for connection setup. I suppose this could be via >> v4v and a connection manager service running in a known and trusted >> domain. But how does a domain find the connection manager service and >> how does it handle the connection management domain being restarted? > Rings are created by a guest listening to v4v. A listener doesn't know in advance which domains might attempt to connect so it must necessarily create a ring that any domain can put messages on. One solution would be to have the per-ring v4vtable rule chains that the ring owner can modify. Or some mechanism by which a ring owner can pause a sender and prevent it temporarily (or permenantly) from placing any messages on the ring. David