From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 7 21:45:56 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30CFE1065673 for ; Sun, 7 Dec 2008 21:45:56 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id EAEE18FC13 for ; Sun, 7 Dec 2008 21:45:55 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (246.10.87-79.rev.gaoland.net [79.87.10.246]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 9519F63366E for ; Sun, 7 Dec 2008 22:45:54 +0100 (CET) Received: from baby-jane (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 2DDCF6728C0 for ; Sun, 7 Dec 2008 22:45:53 +0100 (CET) Date: Sun, 7 Dec 2008 22:45:51 +0100 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: freebsd-hackers@freebsd.org Message-ID: <20081207224551.13ca3590@baby-jane> Organization: /dave/nulle X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i386-apple-darwin9.3.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: crypto(9) choose another driver if we cannot open a session on it X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 21:45:56 -0000 Hello, I wrote a small patch to allow the crypto framework to choose another cryptographic driver if we cannot open a session on the driver. The current version selects the driver that handles all the requested algorithms and with the less count of active sessions. But this is not enough, by example the glxsb(4) driver does not accept AES session with key's length != 128 bits. It rejects also HMAC algorithms if there is no AES encryption to do in the session (HMAC is done by software to make it works with ipsec). The other way to deal with this problem would be to implement in the glxsb driver software implementations for AES 192 et AES 256. (OpenBSD did it recently). But I think this is a hack and it's better to revert to another driver. diff of sys/opencrypto/crypto.c between 8-CURRENT http://user.lamaiziere.net/patrick/opencrypto-071208/crypto.c-diff sys/opencrypto/crypto.c http://user.lamaiziere.net/patrick/opencrypto-071208/crypto.c That should not break anything. It would be nice to test it on a box with a Geode LX CPU and a crypto device like a VPN1411 card. I don't have the hardware but I've checked that we revert to the cryptosoft driver when using ipsec and glxsb with AES key's length != 128 bits. Thanks, regards.