From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: xenconsoled CPU denial of service problem Date: Wed, 04 Oct 2006 13:19:31 -0500 Message-ID: <4523FB33.7080807@us.ibm.com> References: <20060829155900.GC970@redhat.com> <20060911141905.GB26811@redhat.com> <20061004135026.GC474@redhat.com> <4523E634.7050901@us.ibm.com> <20061004171939.GF474@redhat.com> <4523F4F4.1090508@us.ibm.com> <20061004181013.GH474@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20061004181013.GH474@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Daniel P. Berrange" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Daniel P. Berrange wrote: >> Xenconsole could still spit out on a PTY. You don't necessarily need a >> daemon though (you could launch a xenconsole for each domain that was >> started). >> > > The xenconsole would still need the rate-limiting, and once you're launching > one xenconsole per domain, where's the gain over the single xenconsoled > process ? > When the pty is writable, try to read information from ring queue. Only let the pty become readable when there is data in the queue ready to be ready. You only need to listen for event channel notifications when the queue is empty (so you cannot be stormed). Likewise, you don't have to listen for event channel notifications when the queue is full, and you have data to write. The only time you could be DoS is when someone is attached to the PTY and actively reading/writing to it. I would then argue that it's not xenconsole's responsibility to rate limit. It's whoever is reading or writing. >> That also gives you a bit more choice in how you expose the console (you >> could have a xenconsole that spit out via TCP). >> > > Given a TTY, there are already tools which can do this & more. So I don't see > any point in writing such functionality again for Xen. If using HVM domains > one would already typically be exposing a serial console from the guest via > a pseudo-TTY, so doing all PV console stuff via a TTY gives parity in the > management toolset. > I'm happy exposing a pty for the console. I made those same arguments myself when we first did it :-) I'm simply suggesting that we move the buffering to domU. Regards, Anthony Liguori > Regards, > Dan. >