Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200826055150.2753.90553@ml01.vlan13.01.org> <b34f7644-a495-4845-0a00-0aebf4b9db52@molgen.mpg.de>
 <CAMj1kXEUQdmQDCDXPBNb3hRrbui=HVyDjCDoiFwDr+mDSjP43A@mail.gmail.com>
 <20200826114952.GA2375@gondor.apana.org.au> <CAMj1kXGjytfJEbLMbz50it3okQfiLScHB5YK2FMqR5CsmFEBbg@mail.gmail.com>
 <20200826120832.GA2996@gondor.apana.org.au>
In-Reply-To: <20200826120832.GA2996@gondor.apana.org.au>
From:   Andrew Zaborowski <andrew.zaborowski@intel.com>
Date:   Wed, 26 Aug 2020 14:58:02 +0200
Message-ID: <CAOq732JaP=4X9Yh_KjER5_ctQWoauxzXTZqyFP9KsLSxvVH8=w@mail.gmail.com>
Subject: Re: Issue with iwd + Linux 5.8.3 + WPA Enterprise
To:     Herbert Xu <herbert@gondor.apana.org.au>
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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 26 Aug 2020 at 14:10, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Aug 26, 2020 at 01:59:53PM +0200, Ard Biesheuvel wrote:
> > On Wed, 26 Aug 2020 at 13:50, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > >
> > > On Wed, Aug 26, 2020 at 12:40:14PM +0200, Ard Biesheuvel wrote:
> > > >
> > > > It would be helpful if someone could explain for the non-mac80211
> > > > enlightened readers how iwd's EAP-PEAPv0 + MSCHAPv2 support relies on
> > > > the algif_aead socket interface, and which AEAD algorithms it uses. I
> > > > assume this is part of libell?
> > >
> > > I see the problem.  libell/ell/checksum.c doesn't clear the MSG_MORE
> > > flag before doing the recv(2).
> >
> > But that code uses a hash not an aead, afaict.
>
> Good point.  In that case can we please get a strace with a -s
> option that's big enough to capture the crypto data?

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.

Best regards