lkml.org 
[lkml]   [2004]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH/proposal] dm-crypt: add digest-based iv generation mode
On Wed, Feb 25, 2004 at 03:25:24AM +0100, Christophe Saout wrote:
> Am Di, den 24.02.2004 schrieb Matt Mackall um 20:11:
>
> > > + int tfm_size = sizeof(*cc->digest) + cc->digest->__crt_alg->cra_ctxsize;
> > > + char tfm[tfm_size];
> > > [...]
> > > + memcpy(tfm, cc->digest, tfm_size);
> >
> > As this stands, it's rather scary.
> >
> > - it will quietly break when cryptoapi gets fiddled with
>
> Yes, and it's already broken. When putting a lot of stress to the
> filesystem data corruption pops up.
>
> It turned out the hmac code uses an additional scratch pad which is used
> in crypto_hmac_final (the "opad") which was kmalloc'ed. So it isn't even
> inside the context (the one after struct tfm with length cra_ctxsize).
>
> Why that? That kmalloc could have been avoided and the opad could store
> after the tfm struct too (or on the stack of the crypto_hmac_final or is
> it too large?). Yes, I know, ... but it would really be nice not to put
> locks around the calls.


This is insine, there is no reason to have that outside of function scope at
all.

Here's the fix.
http://jlcooke.ca/lkml/hmac_reent.patch

Uses the stack now (peak stack usage will not go up)

James - I'll wrap this one up with my other in one patch. This is a "look
see, say 'OK'" patch.

JLC

--
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.254 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site