[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH resend] allow connecting to xenconsole from remote hosts
On Tue, Sep 26, 2006 at 04:50:37PM +0100, Keir Fraser wrote: > On 26/9/06 16:26, "Muli Ben-Yehuda" <muli@xxxxxxxxxx> wrote: > > > The attached patch makes xenconsole send and receive console messages > > over a remote connection, instead of via stdin/stdout - if given the > > --remote switch. It is useful for proxy'ing real console message or > > other protocol messages (such as gdb) between dom0 and a remote > > host. We're currently using it for proxying gdb between gdbstub in a > > partition that talks gdb over the console page to a remote host > > running gdb. > > > > Changed since last version: > > - fixed compile warning - type of 'buf' in handle_read_fd() should be > > char*, not unsigned char*. > > > > Signed-off-by: Muli Ben-Yehuda <muli@xxxxxxxxxx> > > I should have spotted this before, but I'm unsure whether the message buffer > ring stuff is really needed. It is necessary in theory, although we might be able to get around it in practice. The theory says that an fd is not guaranteed to be writable, so we need a place to store stuff we want to write to it until it becomes writable. The code isn't that complex (it's even using Xen style rings now! :-)) so I don't see what we lose by being correct both in theory and in practice. If you prefer I can split the buffering support into a separate patch to make it easier to bisect should the need arise. > On the write (to the guest) side, we only read from the tty_fd (or > socket in your case) if there is space in the shared console > ring. On the read (from the guest) side, we already have a buffer > (see e.g., buffer_append() in console/daemon/io.c). It may not be > the best buffer code, and we may want to change it in future to > support logging to files, but it does work! So can you not just send > a minimal patch to add socket support? It should be really small > (like 10s of lines). I can certainly do that - in fact, that's what I started with. But even the current xenconsole code suffers from the theoretical problem mentioned above of writing to an fd without checking that it is writable first. All it takes to exploit it is to run `xenconsole | <socket>' and make the system run out of memory so that the socket is temporarily not writable. Granted, if this happens you have bigger problems, but why not do things right? Cheers, Muli _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |