Jivin [EMAIL PROTECTED] lays it down ... > On Sat, 11 Mar 2006 13:41:16 +1100, Herbert Xu said: > > > OK this is not pretty but it is actually correct. Notice how we only > > overstep the mark for E_KEY but never for D_KEY. Since D_KEY is only > > initialised after this, it is OK for us to trash the start of D_KEY. > > I think a big comment block describing this behavior is called for, > as it carries an implicit requirement that D_KEY and E_KEY remain > adjacent in memory. Anybody allocating space between them is in for > a rude awakening....
Sounds like a bug waiting to happen to me. Why not do something like the attached patch. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
Index: linux-2.6.x/crypto/aes.c =================================================================== RCS file: linux-2.6.x/crypto/aes.c,v retrieving revision 1.1.1.6 diff -u -r1.1.1.6 aes.c --- linux-2.6.x/crypto/aes.c 31 Aug 2005 00:33:03 -0000 1.1.1.6 +++ linux-2.6.x/crypto/aes.c 14 Mar 2006 22:53:06 -0000 @@ -78,12 +78,11 @@ struct aes_ctx { int key_length; - u32 E[60]; - u32 D[60]; + u32 _KEYS[120]; }; -#define E_KEY ctx->E -#define D_KEY ctx->D +#define E_KEY (&ctx->_KEYS[0]) +#define D_KEY (&ctx->_KEYS[60]) static u8 pow_tab[256] __initdata; static u8 log_tab[256] __initdata;