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) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
