Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Jul 2015 23:48:43 -0500
From:      "Matthew D. Fuller" <fullermd@over-yonder.net>
To:        "George V. Neville-Neil" <gnn@FreeBSD.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r285336 - in head/sys: netipsec opencrypto
Message-ID:  <20150711044843.GG96394@over-yonder.net>
In-Reply-To: <201507091816.t69IGawf097288@repo.freebsd.org>
References:  <201507091816.t69IGawf097288@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150711044843.GG96394>