Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]

From: Fabrice Bellard <fabrice@bellard.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]
Date: Wed, 07 Apr 2004 22:10:53 +0200	[thread overview]
Message-ID: <4074604D.6030201@bellard.org> (raw)
In-Reply-To: <000701c41cbf$49b386d0$0401a8c0@putte2k>

Hi,

I like very much the idea of enabling network use without any priviledge 
rights for Linux and win32. I have looked at the SLiRP code and it seems 
easy to do (at least for Linux, for win32 I have not looked how to do 
that with the SDL event loop).

Expect this feature to come in the next few days :-)

The idea is the following : the raw ethernet packet coming from the 
virtual NE2000 card will be converted to high level socket operations 
(such as connect TCP connection, socket read/write). It won't work in 
every case (in particular no incoming TCP connection will be supported), 
but will allow at least to browse with the simulated OS. The limitations 
will be close to what you have with a firewall configuration.

Fabrice.

Mike Nordell wrote:
> John R. Hogerhuis wrote
> 
> 
>>On the user space issue, I guess that's not completely true when
>>it comes to networking? You have to be using the TUN/TAP driver.
> 
> 
> This is something I've been thinking about, and maybe, just maybe, I might
> have got an idea to make it work on at least later (host) NT's - the ones
> that can give you raw access, allow you to write your own e.g. IP headers.
> 
> The most likely protocols to encounter would be IP, followed by ICMP. Should
> anyone want IPX, or even NetBEUI - sure, make it a plug-in architecture.
> 
> What if some piece of code was given low-level protocol knowledge, to let
> the OS'es running in QEMU happily think they talk to a NIC (be it NE2k, or a
> card with some more speed and less interrupt requirements), but that the
> emulated card in turn was "connected" to a piece of software, let's for now
> call it the protocol parser (PP), that also knew IP and ICMP?
> 
> I envision this piece of code as either a part of the QEMU process, or a
> separate process (let's not bother about the IPC - that's easy in
> comparison), parsing the emitted ethernet packets from the QEMU virtual NIC,
> and in effect acting as a NAT (and then some).
> 
> Sure, it wouldn't run light lightning, but it could be a completely
> user-mode solution.
> 
> Running this thing as a separate process would probably make it slower, but
> it could also enable the possibility to run the QEMU process(es) with less
> than Administrator privileges - while the component getting this raw access
> to the host NIC obviously would need them. That's the reason I mentioned the
> possibility of emulating anopther card than NE2k, which is probably the most
> inefficient of all NIC's, even if comparatively easy to implement an
> emulator for.
> 
> 
> As for the idea about a SOCKS (or any other kind of) proxy; I'm fairly sure
> that'd only work for operating systems where a QEMU-special implementation
> was created (either by the OS, or in QEMU itself - by trapping syscalls and
> so on), why it wouldn't be a viable solution for but some limited cases. OK,
> it could probably be done without too much effort for e.g. a specific Linux
> version (maybe even many), but from my POV it'd be very fragile in depending
> on specific versions of specific OSes.
> 
> Please don't see this as a suggestion, I'm just bouncing an idea I've had
> for a while.
> 
> 
> /Mike
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 