From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Se91b-0002UR-4o for qemu-devel@nongnu.org; Mon, 11 Jun 2012 14:07:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Se91Z-0008FQ-Bg for qemu-devel@nongnu.org; Mon, 11 Jun 2012 14:07:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Se91Z-0008Em-3F for qemu-devel@nongnu.org; Mon, 11 Jun 2012 14:07:33 -0400 Date: Mon, 11 Jun 2012 14:22:05 -0300 From: Luiz Capitulino Message-ID: <20120611142205.68e86ddb@doriath.home> In-Reply-To: <20120608164856.GB4012@redhat.com> References: <1337619593-25823-1-git-send-email-berrange@redhat.com> <1337619593-25823-4-git-send-email-berrange@redhat.com> <20120530155037.4e5d46df@doriath.home> <20120608164856.GB4012@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 3/3] Add rate limiting of RTC_CHANGE, BALLOON_CHANGE & WATCHDOG events List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Amit Shah , qemu-devel@nongnu.org, Anthony Liguori , Markus Armbruster On Fri, 8 Jun 2012 17:48:56 +0100 "Daniel P. Berrange" wrote: > On Wed, May 30, 2012 at 03:50:37PM -0300, Luiz Capitulino wrote: > > On Mon, 21 May 2012 17:59:53 +0100 > > "Daniel P. Berrange" wrote: > > > > +/* Global, one-time initializer to configure the rate limiting > > > + * and initialize state */ > > > +static void monitor_protocol_event_init(void) > > > +{ > > > + qemu_mutex_init(&monitor_event_state_lock); > > > + /* Limit RTC & BALLOON events to 1 per second */ > > > + monitor_protocol_event_throttle(QEVENT_RTC_CHANGE, 1000); > > > + monitor_protocol_event_throttle(QEVENT_BALLOON_CHANGE, 1000); > > > + monitor_protocol_event_throttle(QEVENT_WATCHDOG, 1000); > > > > What about SUSPENDED and BLOCK_IO_ERROR? Couldn't the former be also > > used by a malicious guest to cause a DoS? The former is already emitted > > several times for virtio. > > This can't be used to filter BLOCK_IO_ERROR, since that event > contains per-device state information. Filtering this would > need to be done in the block layer, so it can done per device. That's right. > I don't think SUSPEND can be used to DoS, since once the VM > is in the suspend state, a monitor command is required to wake > it up again before the guest OS can trigger a new suspend. Can't the guest OS awake itself?