Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>,
	Andrew Zaborowski <andrew.zaborowski@intel.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Paul Menzel <pmenzel@molgen.mpg.de>,
	Caleb Jorden <caljorden@hotmail.com>,
	Sasha Levin <sashal@kernel.org>,
	iwd@lists.01.org, "# 3.4.x" <stable@vger.kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: Issue with iwd + Linux 5.8.3 + WPA Enterprise
Date: Wed, 26 Aug 2020 08:57:17 -0500	[thread overview]
Message-ID: <c27e5303-48d9-04a4-4e73-cfea5470f357@gmail.com> (raw)
In-Reply-To: <20200826130010.GA3232@gondor.apana.org.au>

Hi Herbert,

On 8/26/20 8:00 AM, Herbert Xu wrote:
> On Wed, Aug 26, 2020 at 02:58:02PM +0200, Andrew Zaborowski wrote:
>>
>> Running iwd's and ell's unit tests I can see that at least the
>> following algorithms give EINVAL errors:
>> ecb(aes)
>> cbc(aes)
>> ctr(aes)
>>
>> The first one fails in recv() and only for some input lengths.  The
>> latter two fail in send().  The relevant ell code starts at
>> https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c#n271
>>
>> The tests didn't get to the point where aead is used.
> 
> Yes ell needs to set MSG_MORE after sending the control message.
> Any sendmsg(2) without a MSG_MORE will be interpreted as the end
> of a request.

I'm just waking up now, so I might seem dense, but for my education, can you 
tell me why we need to set MSG_MORE when we issue just a single sendmsg followed 
immediately by recv/recvmsg? ell/iwd operates on small buffers, so we don't 
really feed the kernel data in multiple send operations.  You can see this in 
the ell git tree link referenced in Andrew's reply.

According to https://www.kernel.org/doc/html/latest/crypto/userspace-if.html:

The send system call family allows the following flag to be specified:

     MSG_MORE: If this flag is set, the send system call acts like a cipher 
update function where more input data is expected with a subsequent invocation 
of the send system call.

So given what I said above, the documentation seems to indicate that MSG_MORE 
flag should not be used in our case?

Regards,
-Denis

> 
> I'll work around this in the kernel though for the case where there
> is no actual data, with a WARN_ON_ONCE.
> 
> Thanks,
> 


  reply	other threads:[~2020-08-26 14:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200826055150.2753.90553@ml01.vlan13.01.org>
2020-08-26  6:18 ` Issue with iwd + Linux 5.8.3 + WPA Enterprise Paul Menzel
2020-08-26 10:40   ` Ard Biesheuvel
2020-08-26 11:49     ` Herbert Xu
2020-08-26 11:59       ` Ard Biesheuvel
2020-08-26 12:08         ` Herbert Xu
2020-08-26 12:58           ` Andrew Zaborowski
2020-08-26 13:00             ` Herbert Xu
2020-08-26 13:57               ` Denis Kenzior [this message]
2020-08-26 14:19                 ` Herbert Xu
2020-08-26 15:25                   ` Denis Kenzior
2020-08-26 15:42                     ` Ard Biesheuvel
2020-08-26 22:19                       ` Herbert Xu
2020-08-27  6:40                         ` Ard Biesheuvel
2020-08-27  7:14                           ` [v2 PATCH] crypto: af_alg - Work around empty control messages without MSG_MORE Herbert Xu
2020-08-27  7:40                             ` Ard Biesheuvel
     [not found]                         ` <BL0PR11MB329980406FA0A14A8EF61A07B9550@BL0PR11MB3299.namprd11.prod.outlook.com>
2020-08-27  7:54                           ` Issue with iwd + Linux 5.8.3 + WPA Enterprise Ard Biesheuvel
2020-08-26 13:29             ` [PATCH] crypto: af_alg - Work around empty control messages without MSG_MORE Herbert Xu
2020-08-26 13:56               ` Ard Biesheuvel

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=c27e5303-48d9-04a4-4e73-cfea5470f357@gmail.com \
    --to=denkenz@gmail.com \
    --cc=andrew.zaborowski@intel.com \
    --cc=ardb@kernel.org \
    --cc=caljorden@hotmail.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=iwd@lists.01.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=sashal@kernel.org \
    --cc=stable@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