lkml.org 
[lkml]   [2019]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 04/10] crypto: akcipher - new verify API for public key algorithms
David,

On Thu, Feb 28, 2019 at 07:02:09PM +0000, David Howells wrote:
> | > It's not clear that sig->digest is guaranteed to be kmalloc memory.
>
> Well, public_key_signature_free() will go bang if it's not kfree'able.

Well, I had similar argument, FYI:

| On Fri, Feb 01, 2019 at 10:09:23AM +0300, Vitaly Chikunov wrote:
| > On Fri, Feb 01, 2019 at 02:26:55PM +0800, Herbert Xu wrote:
| > >
| > > It's not clear that sig->digest is guaranteed to be kmalloc memory.
| > > In any case, it's best not to mix unrelated changes in a single
| > > patch. So please keep the kmalloc on output and then copy
| > > sig->digest into it and put output into the SG list.
| >
| > It is not guaranteed that sig->s will be kmalloc memory either. (Except
| > we know it for sure like we know the same about sig->digest).
| >
| > You can see in public_key_signature_free() that both fields are kfree'd
| > together.
| >
| > So, I don't understand why we should treat sig->digest differently than
| > sig->s.
| >
| > I was just removing kmalloc'ed output as crypto_akcipher_verify() does
| > not need any output anymore. So, it's not some sort of mixing unrelated
| > changes, from my point of view.

But then I thought Herbert knows better and implemented his suggestion.

Now I have contradictory requests from two maintainers.


\
 
 \ /
  Last update: 2019-02-28 20:08    [W:0.035 / U:28.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site