Hi,
I am trying to use OpenSSH (which uses the Openssl lib with HW Offload crypto engine support). I am using the patched version of OpenSSL that I submitted. It uses the /dev/crypto interface that was provided by the patch [1] submitted to Opensource.
The interface is provided in such a way that one file descriptor per session is opened. On this fd we set the session, do cipher/hash operations and when done delete the session and close the fd. The problem arises after running this iteration (open, session set, operation and close) for several hundred times (over 500 times), the opening of file /dev/crypto fails with error -2 (no such file). I tried looking at the open system call implementation and found that ?inode = next.dentry->d_inode? is NULL in routine ?__link_path_walk? in fs/namei.c ?which is not the case when it is working.
Why would the opening of /dev/crypto fails only after several hundred iteration??I verified the cryptodev driver functionality and looked at the Openssl code but was not able to determine the cause of the problem. This is with Linux 2.6.28.3.
Any thoughts/suggestions about what could be wrong would be highly appreciated.
Thanks,
Shasi
[1] Add CryptoAPI User Interface Support Patch v6
On Tue, Mar 10, 2009 at 07:46:34PM -0700, Shasi Pulijala wrote:
>
> I am trying to use OpenSSH (which uses the Openssl lib with HW Offload crypto engine support). I am using the patched version of OpenSSL that I submitted. It uses the /dev/crypto interface that was provided by the patch [1] submitted to Opensource.
> The interface is provided in such a way that one file descriptor per session is opened. On this fd we set the session, do cipher/hash operations and when done delete the session and close the fd. The problem arises after running this iteration (open, session set, operation and close) for several hundred times (over 500 times), the opening of file /dev/crypto fails with error -2 (no such file). I tried looking at the open system call implementation and found that “inode = next.dentry->d_inode” is NULL in routine “__link_path_walk” in fs/namei.c which is not the case when it is working.
Loc can probably give a more specific answer to your question.
But I wanted to say something about SSL offload in general. We've
talked about this amongst the networking group and the consensus
seems to be that we should be doing the SSL data path in the kernel.
So rather than using the crypto user-space API for SSL offload, we
should really provide it as through the usual socket interface just
as we do with IPsec.
The SSL control path however should remain in user-space, even if
and when we add public key support to the kernel crypto system.
Though that could and should be made available to user-space SSL
through the crypto user-space API.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt