Received-SPF: pass (google.com: domain of linux-wireless+bounces-4701-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <db86cba4-0e61-441d-8e66-405a13b61a3c@gmail.com>
Date: Wed, 13 Mar 2024 14:17:29 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [REGRESSION] Re: [PATCH] crypto: pkcs7: remove sha1 support
To: Eric Biggers <ebiggers@kernel.org>
Cc: Johannes Berg <johannes@sipsolutions.net>, Karel Balej
 <balejk@matfyz.cz>, dimitri.ledkov@canonical.com,
 alexandre.torgue@foss.st.com, davem@davemloft.net, dhowells@redhat.com,
 herbert@gondor.apana.org.au, keyrings@vger.kernel.org,
 linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org,
 linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org,
 linux-stm32@st-md-mailman.stormreply.com, mcgrof@kernel.org,
 mcoquelin.stm32@gmail.com, linux-wireless@vger.kernel.org,
 netdev@vger.kernel.org, iwd@lists.linux.dev
References: <CZSHRUIJ4RKL.34T4EASV5DNJM@matfyz.cz>
 <005f998ec59e27633b1b99fdf929e40ccfd401c1.camel@sipsolutions.net>
 <f2dcbe55-0f0e-4173-8e21-f899c6fc802a@gmail.com>
 <20240313194423.GA1111@sol.localdomain>
 <b838e729-dc30-4e18-b928-c34c16b08606@gmail.com>
 <20240313202223.GB1111@sol.localdomain>
Content-Language: en-US
From: James Prestwood <prestwoj@gmail.com>
In-Reply-To: <20240313202223.GB1111@sol.localdomain>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 3/13/24 1:22 PM, Eric Biggers wrote:
> On Wed, Mar 13, 2024 at 01:12:54PM -0700, James Prestwood wrote:
>> Hi,
>>
>> On 3/13/24 12:44 PM, Eric Biggers wrote:
>>> On Wed, Mar 13, 2024 at 10:26:06AM -0700, James Prestwood wrote:
>>>> Hi,
>>>>
>>>> On 3/13/24 1:56 AM, Johannes Berg wrote:
>>>>> 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:
>>>>>>     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?

I was not around when the original decision was made, but a few reasons 
I know we don't use openSSL:

  - IWD has virtually zero dependencies.

  - OpenSSL + friends are rather large libraries.

  - AF_ALG has transparent hardware acceleration (not sure if openSSL 
does too).

Another consideration is once you support openSSL someone wants wolfSSL, 
then boringSSL etc. Even if users implement support it just becomes a 
huge burden to carry for the project. Just look at wpa_supplicant's 
src/crypto/ folder, nearly 40k LOC in there, compared to ELL's crypto 
modules which is ~5k. You have to sort out all the nitty gritty details 
of each library, and provide a common driver/API for the core code, 
differences between openssl versions, the list goes on.

Thanks,

James


>
> - Eric