Questions about Optimizing network I/O
Hello, I'm looking for advice on optimizing a SOCKS proxy software which i modified to support TCP <=> UDP tunnelling. The modification of standard SOCKS protocol is pretty straightforward, i've added a command that tells to socks server that destination socket is a UDP socket so the server expects the tcp packets for this destination to be prefixed with 4 byte length. The server reads the length prefix the reads the 'length' bytes for the tcp stream and send the data (without the length prefix) to the destination address as UDP datagram. The return path (from UDP to TCP) is even simpler: The server read UDP datagram into a buffer whre 4 bytes are reserved for length prefix, fill this prefix with the length of just read packet and send the buffer to the tcp socket. When testing my SOCKS server i see that the TCP -> UDP processing generates a lot o CPU load while UDP -> TCP or normal SOCKS TCP <=> TCP processing generates relatively light cpu load. So i'm looking for the way to optimize TCP -> UDP path. My idea is to write a kernel module which will define an ioctl with 2 params TCP_fd and UDP_fd and will do TCP to UDP processing completely in kernel mode without copying data frmo/to skbufs Any ideas about this approach? Thanks Vadim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Questions about Optimizing network I/O
Hello, I'm looking for advice on optimizing a SOCKS proxy software which i modified to support TCP = UDP tunnelling. The modification of standard SOCKS protocol is pretty straightforward, i've added a command that tells to socks server that destination socket is a UDP socket so the server expects the tcp packets for this destination to be prefixed with 4 byte length. The server reads the length prefix the reads the 'length' bytes for the tcp stream and send the data (without the length prefix) to the destination address as UDP datagram. The return path (from UDP to TCP) is even simpler: The server read UDP datagram into a buffer whre 4 bytes are reserved for length prefix, fill this prefix with the length of just read packet and send the buffer to the tcp socket. When testing my SOCKS server i see that the TCP - UDP processing generates a lot o CPU load while UDP - TCP or normal SOCKS TCP = TCP processing generates relatively light cpu load. So i'm looking for the way to optimize TCP - UDP path. My idea is to write a kernel module which will define an ioctl with 2 params TCP_fd and UDP_fd and will do TCP to UDP processing completely in kernel mode without copying data frmo/to skbufs Any ideas about this approach? Thanks Vadim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potenitial security hole in the kernel
Kurt, Maybe i'm missing something but it seems that during execution of the signal handler, user mode stack contains kernel mode context... Hence the security hole Vadim - Original Message - From: "Kurt Roeckx" <[EMAIL PROTECTED]> To: "Vadim Lebedev" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, May 29, 2001 12:29 AM Subject: Re: Potenitial security hole in the kernel > On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote: > > Hi folks, > > > > Please correct me if i'm wrong but it seems to me that i've stumbled on > > really BIG security hole in the signal handling code. > > The problem IMO is that the signal handling code stores a processor context > > on the user-mode stack frame which is active while > > And how is that different from any other function call? > > > Kurt > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potenitial security hole in the kernel
Philip, The point is the panic will be executed in KERNEL and NOT user mode. Unless i'm missing something the sigcontext contains kernel mode and not user mode context. Vadim - Original Message - From: "Philip Blundell" <[EMAIL PROTECTED]> To: "Vadim Lebedev" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, May 29, 2001 12:21 AM Subject: Re: Potenitial security hole in the kernel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Potenitial security hole in the kernel
Hi folks, Please correct me if i'm wrong but it seems to me that i've stumbled on really BIG security hole in the signal handling code. The problem IMO is that the signal handling code stores a processor context on the user-mode stack frame which is active while the signal handler is running. Then sys_sigreturn restores back the context from user mode stack... Suppose the signal handler modifies this context frame for example by storing into the PC slot address of the panic routine then when handler will exit panic will be called with obvious results. Please CC your comments to me directly as i'm not subscibed to this list Vadim Lebedev - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Potenitial security hole in the kernel
Hi folks, Please correct me if i'm wrong but it seems to me that i've stumbled on really BIG security hole in the signal handling code. The problem IMO is that the signal handling code stores a processor context on the user-mode stack frame which is active while the signal handler is running. Then sys_sigreturn restores back the context from user mode stack... Suppose the signal handler modifies this context frame for example by storing into the PC slot address of the panic routine then when handler will exit panic will be called with obvious results. Please CC your comments to me directly as i'm not subscibed to this list Vadim Lebedev - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potenitial security hole in the kernel
Kurt, Maybe i'm missing something but it seems that during execution of the signal handler, user mode stack contains kernel mode context... Hence the security hole Vadim - Original Message - From: Kurt Roeckx [EMAIL PROTECTED] To: Vadim Lebedev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, May 29, 2001 12:29 AM Subject: Re: Potenitial security hole in the kernel On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote: Hi folks, Please correct me if i'm wrong but it seems to me that i've stumbled on really BIG security hole in the signal handling code. The problem IMO is that the signal handling code stores a processor context on the user-mode stack frame which is active while And how is that different from any other function call? Kurt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potenitial security hole in the kernel
Philip, The point is the panic will be executed in KERNEL and NOT user mode. Unless i'm missing something the sigcontext contains kernel mode and not user mode context. Vadim - Original Message - From: Philip Blundell [EMAIL PROTECTED] To: Vadim Lebedev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, May 29, 2001 12:21 AM Subject: Re: Potenitial security hole in the kernel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
I'm attaching a module i'm using to write C++ drivers for linux 2.0.xx The following line goes into the Rules.make file %.o: %.cpp $(CC) -fno-exceptions -fno-rtti $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_DEBUG) -c -o $@ $< For me it is working really great the new.cpp file goes in my arch//lib directory Vadim new.cpp
Re: Linux kernel modules development in C++
I'm attaching a module i'm using to write C++ drivers for linux 2.0.xx The following line goes into the Rules.make file %.o: %.cpp $(CC) -fno-exceptions -fno-rtti $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_DEBUG) -c -o $@ $ For me it is working really great the new.cpp file goes in my arch//lib directory Vadim new.cpp
