public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Christophe Saout <christophe@saout.de>
Cc: Jean-Luc Cooke <jlcooke@certainkey.com>,
	linux-kernel@vger.kernel.org,
	James Morris <jmorris@intercode.com.au>
Subject: Re: [PATCH/proposal] dm-crypt: add digest-based iv generation mode
Date: Thu, 26 Feb 2004 14:02:45 -0600	[thread overview]
Message-ID: <20040226200244.GH3883@waste.org> (raw)
In-Reply-To: <1077824146.14794.8.camel@leto.cs.pocnet.net>

On Thu, Feb 26, 2004 at 08:35:46PM +0100, Christophe Saout wrote:
> Am Mi, den 25.02.2004 schrieb Matt Mackall um 22:43:
> 
> > Ok, here's my proposed API extension (currently untested). Christophe,
> > care to give it a spin?
> >
> > diff -puN crypto/api.c~crypto-copy crypto/api.c
> > --- tiny/crypto/api.c~crypto-copy	2004-02-25 15:12:43.000000000 -0600
> > +++ tiny-mpm/crypto/api.c	2004-02-25 15:37:39.000000000 -0600
> > @@ -161,6 +161,27 @@ void crypto_free_tfm(struct crypto_tfm *
> >  	kfree(tfm);
> >  }
> >  
> > +int crypto_copy_tfm(char *dst, const struct crypto_tfm *src, unsigned size)
> > +{
> > +	int s = crypto_tfm_size(src);
> > +
> > +	if (size < s)
> > +		return 0;
> 
> Why the extra check?

User is giving us the size of his buffer, not the size of the tfm
which we already know. We refuse to copy if buffer is not big enough,
otherwise return number of bytes copied. This may seem a little
redundant for the on-stack usage of the API, but may make sense in
other cases.
 
> > +void crypto_cleanup_copy_tfm(char *user_tfm)
> > +{
> > +	crypto_exit_ops((struct crypto_tfm *)user_tfm);
> 
> This looks dangerous. The algorithm might free a buffer. This is only
> safe if we introduce per-algorithm copy methods that also duplicate
> external buffers.

I'm currently working under the assumption that such external buffers
are unnecessary but I haven't done the audit. If and when such code
exist, such code should be added, yes. Hence the comment in the copy
function:

+       /* currently assumes shallow copy is sufficient */

> I'd like to avoid a kmalloc in crypto_copy_tfm.

Well you're in luck because there isn't one.

> This function also does the same as crypto_free_tfm except for the
> final kfree(tfm). So crypto_free_tfm could call this function. 

Yes.

> And it could have a better name.

Just about everything could have a better name if the poets among us
were to speak up.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

  reply	other threads:[~2004-02-26 20:05 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-19 17:02 [PATCH/proposal] dm-crypt: add digest-based iv generation mode Christophe Saout
2004-02-19 19:18 ` Andrew Morton
2004-02-20 17:14   ` Jean-Luc Cooke
2004-02-20 18:53     ` Christophe Saout
2004-02-20 19:09       ` Jean-Luc Cooke
2004-02-20 19:23         ` Christophe Saout
2004-02-20 21:23         ` James Morris
2004-02-20 22:40       ` Christophe Saout
2004-02-21  0:07         ` James Morris
2004-02-21  2:17     ` Christophe Saout
2004-02-24 19:11       ` Matt Mackall
2004-02-24 19:43         ` Christophe Saout
2004-02-24 20:38           ` Matt Mackall
2004-02-25 21:43             ` Matt Mackall
2004-02-26 19:35               ` Christophe Saout
2004-02-26 20:02                 ` Matt Mackall [this message]
2004-02-27 16:05                   ` Christophe Saout
2004-02-27 18:37                     ` Christophe Saout
2004-02-27 20:02                     ` Matt Mackall
2004-02-27 20:13                       ` Christophe Saout
2004-02-27 20:55                         ` Matt Mackall
2004-02-27 21:16                           ` Christophe Saout
2004-02-28  0:39                             ` Matt Mackall
2004-02-28 13:02                               ` Christophe Saout
2004-02-24 22:26           ` James Morris
2004-02-24 22:31             ` Christophe Saout
2004-02-24 22:45               ` James Morris
2004-02-24 20:01         ` James Morris
2004-02-24 20:24           ` Matt Mackall
2004-02-25  2:25         ` Christophe Saout
2004-02-25  3:05           ` Jean-Luc Cooke
2004-02-23  0:35 ` Fruhwirth Clemens
2004-02-23 13:44   ` Jean-Luc Cooke
2004-02-23 15:36     ` James Morris
     [not found] <20040223214738.GD24799@certainkey.com>
     [not found] ` <Xine.LNX.4.44.0402231710390.21142-100000@thoron.boston.redhat.com>
2004-02-24 20:22   ` Jean-Luc Cooke
2004-02-24 22:17     ` James Morris
2004-02-24 22:44       ` Jean-Luc Cooke
2004-02-25 13:52         ` James Morris
2004-02-25 15:11           ` Jean-Luc Cooke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040226200244.GH3883@waste.org \
    --to=mpm@selenic.com \
    --cc=christophe@saout.de \
    --cc=jlcooke@certainkey.com \
    --cc=jmorris@intercode.com.au \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox