Date: Sun, 7 Dec 2008 22:45:51 +0100 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= <patfbsd@davenulle.org> To: freebsd-hackers@freebsd.org Subject: crypto(9) choose another driver if we cannot open a session on it Message-ID: <20081207224551.13ca3590@baby-jane>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081207224551.13ca3590>