Karl O. Pinc wrote: > On 04/24/2009 07:40:02 AM, Siim Põder wrote: [snip]
> Please pardon me for thinking out loud here... I'll follow in this path, thinking out loud ... > The problem is that moving data between userspace and kernelspace > is expensive. (IIRC you can't just use the CPU to filter the bus > between nics, you need to deliver data to/receive data > from RAM because that's where the userland app works > with it.) OpenVPN runs in userspace so all the VPN data > has to pass out of the kernel into userspace and back again. > To attack the problem directly you need to move all functionality > into the kernel, which raises a number of problems. > Such an OpenVPN would not port between OS platforms > very well. Someone would have to convince both > the kernel and OpenVPN developers to maintain the > code. And so forth. This actually made me think a little bit. For the Windows platform, OpenVPN ship a TUN/TAP driver as a part of the installation, due to missing native tun/tap drivers. What if OpenVPN on selected platforms also provided it's own kernel driver which would do practically the same as the upstream tun.ko modules - except it provides a direct API which OpenVPN can utilize, to avoid the kernel-userspace-kernel ping-pong. But I also do realise that, a poorly written API can introduce some really nasty security breaches as well. And I also realise that it will be more code to maintain. Such an implementation should probably try to make use of the kernel based encryption API as well, as that might be also much more efficient in this setting. Just my 2cents. David Sommerseth
