Date: Thu, 08 Jan 1998 00:03:29 +1030 From: Mike Smith <mike@smith.net.au> To: daniel_sobral@voga.com.br Cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: Device Driver Message-ID: <199801071333.AAA01091@word.smith.net.au> In-Reply-To: Your message of "Wed, 07 Jan 1998 08:44:09 -0300." <83256585.003EA128.00@papagaio.voga.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Will you be using it to perform end-to-end encryption on sockets? > > Yup. > > > How about encrypting the entire contents of ethernet datagrams? > > Nope. Only the contents of IP packets. Possibly the contents of UDP and TCP > packets instead (as I said, that part I am not responsible for). OK. > > Is the output of the card complete in itself, or > > does it encrypt streams of data? > > Apart from the various miscellaneous functions, which fit nicely into > ioctl, the card does stream encryption, though access to it may be > optimized by using it's 8-byte internal buffer. Fair enough. How do you maintain state for each open stream? > > Again, that depends on how you talk to it. Sometimes you will use the > > standard device entries (if you plan to use those semantics from > > elsewhere in the kernel), and sometimes you need other interfaces. > > The problem I see with using the standard device interface is the proc* > parameter. The net functions calling the driver will be activated by > interrupts. This is not necessarily the case. For outbound data, the call to enqueue the data (at least) will be made by the sending process. It would not be unreasonable for the send to block the process until encryption is completed. For incoming data, the decryption could be postponed until the consumer actually reads from the socket, although as soon as you have a socket in mind you have access to the proc structure belonging to the socket's owner. Another alternative would be to create a kernel process (like the update daemon) which serviced the encryption/decryption queues. This would give you a process context on which you could sleep. > BTW, let me ask a question before I forget it again... :-) The driver > itself has no interrupt handler. Now, I intend to use a queue to control > the access to the card, and the queue manipulation section is critical. > These routines _may_ be called from other interrupt handlers. So, should I > spl them? At what level? What level are you going to call them from? Are you capable of writing queue manipulation code that can survive interleaved head and tail operations? If not, you want to make sure that you spl them high enough to avoid any reentry. If in doubt, err on the side of caution. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801071333.AAA01091>