Re: Issue with iwd + Linux 5.8.3 + WPA Enterprise

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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,





[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux