svn commit: r285336 - in head/sys: netipsec opencrypto

[Matthew D. Fuller]

On Thu, Jul 09, 2015 at 06:16:36PM +0000 I heard the voice of
George V. Neville-Neil, and lo! it spake thus:
> New Revision: 285336
> URL: https://svnweb.freebsd.org/changeset/base/285336
> 
> Log:
>   Add support for AES modes to IPSec.  These modes work both in software only
>   mode and with hardware support on systems that have AESNI instructions.

With (apparently) this change, I can trigger a panic at will by
running

% geli onetime -e AES-XTS -d /dev/ada0s1

My best guess is that it comes from

> -#define RIJNDAEL128_BLOCK_LEN	16
> +#define	AES_MIN_BLOCK_LEN	1

> -	RIJNDAEL128_BLOCK_LEN, 8, 32, 64,
> +	AES_MIN_BLOCK_LEN, AES_XTS_IV_LEN, AES_XTS_MIN_KEY, AES_XTS_MAX_KEY,

changing that first arg from 16 to 1.  It seems to be avoided with the
following patch:

------8K--------

Index: sys/opencrypto/xform.c
===================================================================
--- sys/opencrypto/xform.c	(revision 285365)
+++ sys/opencrypto/xform.c	(working copy)
@@ -257,7 +257,7 @@
 
 struct enc_xform enc_xform_aes_xts = {
 	CRYPTO_AES_XTS, "AES-XTS",
-	AES_MIN_BLOCK_LEN, AES_XTS_IV_LEN, AES_XTS_MIN_KEY, AES_XTS_MAX_KEY,
+	AES_BLOCK_LEN, AES_XTS_IV_LEN, AES_XTS_MIN_KEY, AES_XTS_MAX_KEY,
 	aes_xts_encrypt,
 	aes_xts_decrypt,
 	aes_xts_setkey,

------8K--------

at least in a little testing here.  If that's the actual fix, some of
the other MIN_BLOCK_LEN changes in GCM and GMAC are probably suspect
too.


(I also wonder why AES-ICM is still using the RIJNDAEL128 #defines;
shouldn't it be using the AES's too?  But that's cosmtic...)


-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.