Date: Tue, 31 Jul 2001 03:33:19 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Anjali Kulkarni <anjali@indranetworks.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: inet_aton Message-ID: <3B66896F.7E0300EF@mindspring.com> References: <002d01c11728$d34723b0$0a00a8c0@indranet> <3B6325B7.D6CBC67A@mindspring.com> <008701c1199c$98684f50$0a00a8c0@indranet>
next in thread | previous in thread | raw e-mail | index | archive | help
Anjali Kulkarni wrote: > Thanks for your response. I am new to kernel programming, and so cud u tell > me why it is a bad idea to pass strings to the kernel? Is it due to static > memory is used etc.? > Actually, I am not passing strings to the kernel, I am writing code in > kernel which has a remote server's ip-address string, and I need to connect > to the remote server, so I need to use inet_aton..... In general, string manipulation in the kernel is a bad idea. The problem is that C strings are subject to buffer overflows, etc., and dragging them into the kernel makes the kernel vulnerable to similar attacks. To copy the string in, you will call a "copyinstr()" function with arguments, including the address of the kernel buffer in which to copy, and the size of that buffer. If your string length exceeds the buffer size, it is up to you to properly NUL terminate the string: if you don't, you risk running off into memory when iterating the string for length, etc.. A failure there can result in a panic. The other issue here is that inet_aton() is IPv4 specific, so your code will fail with IPv6. In addition, the coversion functions turn out to be fairly heavy weight. Finally, the idea of dragging a lot of new string manipulation functions into the kernel is really, really bad: it will encourage more prople to use them, or, worse, do the same, with their own string manipulation functions. The real question, I guess, is that you say "...kernel which has a remote server's ip-address string...": how did it get this string, if you didn't provide it the information? Even if it got the information from its peer, the most correct thing to do would be to pass the address to a user space process for the translation, and get it passed back into the kernel as a struct sockaddr *. Really, you are only ever going to need this information to do connection setup or teardown, and amortizing the cost of doing this over the lifetime of the connection is going to make the overall costs very, very low; it will also give your kernel access to the DNS services in user space, which you will have a very hard time jamming into the kernel, should you decide that you need to translate not only IP addresses, but names, as well. If you get the information from user space, then the answer is trivial: push it into the kernel as a struct sockaddr * and do a copyin on it based on the type (see the "bind" and "connect" code on how this is done). This means you will have a control program in user space, but still do theheavy lifting in the kernel. There's a great tendency these days to jam much user space functionality into the kernel, on the theory that it will make that functionality faster; in general, though, it tends to bloat the kernel with non-swappable pages (e.g. kernel code and data), which then steals memory from your primary application. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B66896F.7E0300EF>