RE: porting openssl to linux kernel
Even if it were viable to put openssl in the kernel, I personally think that this would create more problems than it solves. For instance, any bug in the openssl code could potentially crash the kernel, rather than simply segfaulting. (I'm typing this in vmware, which has its own kernel modules and it has taken out my Linux machine several times). Also, do you really want to reboot or recompile your kernel for every upgrade to openssl? I've got some machines that have been running for over a year, so I don't see any benefit there. As machines are getting faster and faster all the time, the length of time required for a context switch is also becoming shorter and shorter. If that's the only reason to do it, it's really not worth it, IMNSHO. Now if the linux kernel had accessibility built in, eg keyboard control of voice synthesisers like a dectalk, that would be useful. - John Airey Internet systems support officer, ITCSD, Royal National Institute for the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [EMAIL PROTECTED] -Original Message- From: Rich Salz [mailto:[EMAIL PROTECTED]] Sent: 01 November 2001 01:01 To: Imran Badr Cc: [EMAIL PROTECTED] Subject: Re: porting openssl to linux kernel So far the complication has not proven to be worth it to anyone to implement. Go for it. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] - NOTICE: The information contained in this email and any attachments is confidential and may be legally privileged. If you are not the intended recipient you are hereby notified that you must not use, disclose, distribute, copy, print or rely on this email's content. If you are not the intended recipient, please notify the sender immediately and then delete the email and any attachments from your system. RNIB has made strenuous efforts to ensure that emails and any attachments generated by its staff are free from viruses. However, it cannot accept any responsibility for any viruses which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: porting openssl to linux kernel
Imran Badr wrote: I think Eric Rescorla responded to a similar question sometimes ago that RSA operation would be a limiting factor. But if you take that bottleneck away then I think putting SSL handshake and record porcessing layers in kernel space would be a next better thing to do because we can see many new hardware accelerators out there in the near future market which are 10-20 times better than what we have today. We can have certficate management in the user space for the sake of simplicity. Any comments ??? We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. - Donald Knuth Andreas. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: porting openssl to linux kernel
The (un)encrypted data stream is already coming from the kernel ( socket read/write ) calls. So if everyting is in kernel space then you again save yourself from the overhead of context switch in reading/writing sockets ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rich Salz Sent: Wednesday, October 31, 2001 5:53 AM To: [EMAIL PROTECTED] Subject: Re: porting openssl to linux kernel The matter here is not to be more secure but definitely one can go faster. The guys who use hardware acceleration normally use device drivers which reside in kernel space. Now for every operation, the system has to take a context switch which could be expensive. But if openssl resides in kernel space then instead of calling a device driver it would be just another function call. Does it make sense now?? If you put the hardware crypto into the kernel, then you replace the crypto context switch -- which only transfers a small amount of data, typically an RSA-encrypted RC4 session key -- with a new context switch that transfers a LARGE amount of data, the (un)encrypted data stream. Performance would probably be MUCH WORSE. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: porting openssl to linux kernel
I think Eric Rescorla responded to a similar question sometimes ago that RSA operation would be a limiting factor. But if you take that bottleneck away then I think putting SSL handshake and record porcessing layers in kernel space would be a next better thing to do because we can see many new hardware accelerators out there in the near future market which are 10-20 times better than what we have today. We can have certficate management in the user space for the sake of simplicity. Any comments ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Imran Badr Sent: Wednesday, October 31, 2001 12:15 PM To: [EMAIL PROTECTED] Subject: RE: porting openssl to linux kernel The (un)encrypted data stream is already coming from the kernel ( socket read/write ) calls. So if everyting is in kernel space then you again save yourself from the overhead of context switch in reading/writing sockets ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rich Salz Sent: Wednesday, October 31, 2001 5:53 AM To: [EMAIL PROTECTED] Subject: Re: porting openssl to linux kernel The matter here is not to be more secure but definitely one can go faster. The guys who use hardware acceleration normally use device drivers which reside in kernel space. Now for every operation, the system has to take a context switch which could be expensive. But if openssl resides in kernel space then instead of calling a device driver it would be just another function call. Does it make sense now?? If you put the hardware crypto into the kernel, then you replace the crypto context switch -- which only transfers a small amount of data, typically an RSA-encrypted RC4 session key -- with a new context switch that transfers a LARGE amount of data, the (un)encrypted data stream. Performance would probably be MUCH WORSE. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: porting openssl to linux kernel
On Wed, Oct 31, 2001 at 12:35:25PM -0800, Imran Badr wrote: I think Eric Rescorla responded to a similar question sometimes ago that RSA operation would be a limiting factor. But if you take that bottleneck away then I think putting SSL handshake and record porcessing layers in kernel space would be a next better thing to do because we can see many new hardware accelerators out there in the near future market which are 10-20 times better than what we have today. We can have certficate management in the user space for the sake of simplicity. Any comments ??? Since most implementations don't use Accelerators for symetric operations, it might be interesting to start with a split implementation. Record layer symetric processing in the kernel, retaining the handshake and public key management in user space... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Imran Badr Sent: Wednesday, October 31, 2001 12:15 PM To: [EMAIL PROTECTED] Subject: RE: porting openssl to linux kernel The (un)encrypted data stream is already coming from the kernel ( socket read/write ) calls. So if everyting is in kernel space then you again save yourself from the overhead of context switch in reading/writing sockets ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rich Salz Sent: Wednesday, October 31, 2001 5:53 AM To: [EMAIL PROTECTED] Subject: Re: porting openssl to linux kernel The matter here is not to be more secure but definitely one can go faster. The guys who use hardware acceleration normally use device drivers which reside in kernel space. Now for every operation, the system has to take a context switch which could be expensive. But if openssl resides in kernel space then instead of calling a device driver it would be just another function call. Does it make sense now?? If you put the hardware crypto into the kernel, then you replace the crypto context switch -- which only transfers a small amount of data, typically an RSA-encrypted RC4 session key -- with a new context switch that transfers a LARGE amount of data, the (un)encrypted data stream. Performance would probably be MUCH WORSE. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) he Hat) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: porting openssl to linux kernel
So far the complication has not proven to be worth it to anyone to implement. Go for it. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
porting openssl to linux kernel
Hi, Has anyone ported openssl (completely or partially) to the linux kernel 2.4 or earlier? Thanks, Imran. __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: porting openssl to linux kernel
On Mon, 29 Oct 2001, Imran Badr wrote: Has anyone ported openssl (completely or partially) to the linux kernel 2.4 or earlier? The question has already been asked, and the answer, in short, is: no, there's no need for this (you won't go faster, it won't be more secure, ...). In fact, OpenSSL clearly belongs to the user world, and I (personaly) don't see the point in putting it into the kernel. Or maybe we should put Kerberos, PAM, Nessus, and other security tools into the kernel? No, thanks. -- Erwann ABALEA [EMAIL PROTECTED] RSA PGP Key ID: 0x2D0EABD5 - Stupidity has no limits, genius does. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
