From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45282) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVMvq-000737-V5 for qemu-devel@nongnu.org; Fri, 18 May 2012 09:09:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SVMvp-0005Iy-3N for qemu-devel@nongnu.org; Fri, 18 May 2012 09:09:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVMvo-0005IU-SJ for qemu-devel@nongnu.org; Fri, 18 May 2012 09:09:21 -0400 Date: Fri, 18 May 2012 10:09:34 -0300 From: Luiz Capitulino Message-ID: <20120518100934.0c7b2294@doriath.home> In-Reply-To: <4FB56BAA.8070409@codemonkey.ws> References: <1337163047-6159-1-git-send-email-berrange@redhat.com> <20120516154245.0d9b0cec@doriath.home> <4FB3F8DA.4030809@codemonkey.ws> <20120517074944.GB24943@redhat.com> <20120517095635.4237f903@doriath.home> <4FB56BAA.8070409@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Add event notification for guest balloon changes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Amit Shah , qemu-devel@nongnu.org, Markus Armbruster On Thu, 17 May 2012 16:20:42 -0500 Anthony Liguori wrote: > >> Hmm, that's a good point, but my concern was that if we only emit > >> the event when the target is reached, what happens if the guest > >> gets very close to the target but never actually reaches it for > >> some reason. > > > > Having a way to detect the last balloon change would be perfect. > > libvirt certainly would have to maintain a timeout and make a decision on what > to do if the guest doesn't balloon to target. Not sure how having events help > at all here. I meant that if there's a way to detect the last balloon change, then that's the time we could emit BALLOON_CHANGE (vs. emitting only when the target is reached). I don't think the timeout is a bad idea, though. > >> Should we perhaps just rate limit it to once per second ? > >> > >> BTW, if we're considering guest initiated events to be a potential > >> DOS in this way, then I should point out the RTC_CHANGE event > >> will already suffer this way, if a malicious guest continually > >> adjusts its hardware close. So we might want to apply rate limiting > >> to that event too ? > > > > I think several events can suffer from that. For example, a VNC > > client could repeatedly connect& disconnect from QEMU. If we're going > > to fix this, then we'd need a general solution for it. > > No, VNC clients are a whole different ballgame. VNC connections will only > happen from the management network, we don't worry about memory allocation from > malicious VNC clients. That's true, but as far as an event floods are concerned, I'm not completely sure we should trust the management network. But that was only an example, I think that the SUSPENDED event could also be used by a malicious guests the way Daniel describes above.