On Wed, Mar 13, 2024 at 01:12:54PM -0700, James Prestwood wrote:

Hi,

On 3/13/24 12:44 PM, Eric Biggers wrote:

quoted

On Wed, Mar 13, 2024 at 10:26:06AM -0700, James Prestwood wrote:

quoted

Hi,

On 3/13/24 1:56 AM, Johannes Berg wrote:

quoted

Not sure why you're CC'ing the world, but I guess adding a few more
doesn't hurt ...

On Wed, 2024-03-13 at 09:50 +0100, Karel Balej wrote:

quoted

   and I use iwd

This is your problem, the wireless stack in the kernel doesn't use any
kernel crypto code for 802.1X.

Yes, the wireless stack has zero bearing on the issue. I think that's what
you meant by "problem".

IWD has used the kernel crypto API forever which was abruptly broken, that
is the problem.

The original commit says it was to remove support for sha1 signed kernel
modules, but it did more than that and broke the keyctl API.

Which specific API is iwd using that is relevant here?
I cloned https://kernel.googlesource.com/pub/scm/network/wireless/iwd
and grepped for keyctl and AF_ALG, but there are no matches.

IWD uses ELL for its crypto, which uses the AF_ALG API:

https://git.kernel.org/pub/scm/libs/ell/ell.git/

Thanks for pointing out that the relevant code is really in that separate
repository.  Note, it seems that keyctl() is the problem here, not AF_ALG.  The
blamed commit didn't change anything for AF_ALG.

I believe the failure is when calling:

KEYCTL_PKEY_QUERY enc="x962" hash="sha1"

From logs Michael posted on the IWD list, the ELL API that fails is:

l_key_get_info (ell.git/ell/key.c:416)

Okay, I guess that's what's actually causing the problem.  KEYCTL_PKEY_* are a
weird set of APIs where userspace can ask the kernel to do asymmetric key
operations.  It's unclear why they exist, as the same functionality is available
in userspace crypto libraries.

I suppose that the blamed commit, or at least part of it, will need to be
reverted to keep these weird keyctls working.

For the future, why doesn't iwd just use a userspace crypto library such as
OpenSSL?

- Eric