All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ell@lists.01.org
Subject: Re: [PATCH 08/11] cipher: Update for current kernel akcipher interface
Date: Thu, 09 Jun 2016 16:06:26 -0500	[thread overview]
Message-ID: <5759DA52.2060601@gmail.com> (raw)
In-Reply-To: <alpine.OSX.2.20.1606091301550.21471@mjmartin-mac01.local>

[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]

Hi Mat, Andrew,

On 06/09/2016 03:20 PM, Mat Martineau wrote:
> On Tue, 7 Jun 2016, Mat Martineau wrote:
>
>> On Tue, 7 Jun 2016, Denis Kenzior wrote:
>>>>>> @@ -1078,11 +1068,14 @@ static bool tls_rsa_verify(struct l_tls *tls,
>>>>>> const uint8_t *in, size_t len,
>>>>>>            */
>>>>>>       }
>>>>>>
>>>>>> -    digest_info = alloca(expected_len);
>>>>>> +    if (expected_len > key_size)
>>>>>> +        goto err_free_rsa;
>>>>>> +
>>>>>> +    digest_info = alloca(key_size);
>>>>>
>>>>> This looks like a separate fix and belongs in a separate patch.
>>>>>
>>>>
>>>> What happened here is that the kernel no longer lets you read only the
>>>> amount of data you're expecting - you need to read the maximum size you
>>>> might get. And if I'm telling the kernel to read a potentially larger
>>>> number of bytes, there needs to be a big enough buffer for it.
>>>>
>>>
>>> This still feels wrong to me.  Are you sure its not related to the
>>> PKCS1.5 padding ?
>>
>> Yes. akcipher_recvmsg() does this check before invoking any crypto ops:
>>
>>        /* ensure output buffer is sufficiently large */
>>        if (usedpages < akcipher_calcsize(ctx)) {
>>                err = -EMSGSIZE;
>>                goto unlock;
>>        }
>>
>> (where akcipher_calcsize() returns the key size in bytes when using RSA)
>>
>> I'm not sure why, since the length of the destination buffer gets
>> propagated to the crypto algorithm and it could decide what to do.
>> I'll ask Stephan.
>
> I convinced the author to drop this extra length check. This means we
> can do short reads when using RSA software crypto. However, I see that
> hardware drivers can require the full length output buffer anyway
> (probably because of how the hardware handles DMA access) - so we
> sacrifice compatibility if we use a smaller read buffer.

We still have the issue of pkcs1 pad template...

But my opinion is: 'If this is needed, then this is needed.'  So I have 
no problem doing it this way.

Andrew, thoughts?

Regards,
-Denis

  reply	other threads:[~2016-06-09 21:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-06 20:54 [PATCH 01/11] gitignore: Add unit/test-dbus-message-fds Mat Martineau
2016-06-06 20:54 ` [PATCH 02/11] main: Fix comment typo Mat Martineau
2016-06-06 20:54 ` [PATCH 03/11] unit: Free all memory allocated during the DH test Mat Martineau
2016-06-06 20:54 ` [PATCH 04/11] unit: Script and config file for creating test certificates Mat Martineau
2016-06-06 20:54 ` [PATCH 05/11] unit: New set of " Mat Martineau
2016-06-06 20:54 ` [PATCH 06/11] key: Add keyring APIs Mat Martineau
2016-06-06 20:54 ` [PATCH 07/11] unit: Keyring tests Mat Martineau
2016-06-06 20:54 ` [PATCH 08/11] cipher: Update for current kernel akcipher interface Mat Martineau
2016-06-06 23:55   ` Denis Kenzior
2016-06-07 17:51   ` Denis Kenzior
2016-06-07 19:10     ` Mat Martineau
2016-06-07 19:32       ` Denis Kenzior
2016-06-08  0:18         ` Mat Martineau
2016-06-09 20:20           ` Mat Martineau
2016-06-09 21:06             ` Denis Kenzior [this message]
2016-06-09 21:18               ` Mat Martineau
2016-06-09 21:20             ` Andrzej Zaborowski
2016-06-07 21:47     ` Andrzej Zaborowski
2016-06-07 22:23       ` Denis Kenzior
2016-06-07 22:43         ` Andrzej Zaborowski
2016-06-06 20:54 ` [PATCH 09/11] unit: Update for akcipher changes Mat Martineau
2016-06-06 20:54 ` [PATCH 10/11] cipher: Return result length from asymmetric cipher operations Mat Martineau
2016-06-06 20:54 ` [PATCH 11/11] tls: Free cert memory after sending cert Mat Martineau
2016-06-07 17:54 ` [PATCH 01/11] gitignore: Add unit/test-dbus-message-fds Denis Kenzior

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=5759DA52.2060601@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ell@lists.01.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.