netdev - Re: Openssl/Openssh Offload to Linux Crypto

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20090311030750.GA17900@gondor.apana.org.au>
Date:	Wed, 11 Mar 2009 11:07:50 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Shasi Pulijala <spulijala@...c.com>
Cc:	linux-crypto@...r.kernel.org, Loc Ho <lho@...c.com>,
	netdev@...r.kernel.org
Subject: Re: Openssl/Openssh Offload to Linux Crypto

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~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html