linux-kernel - Re: [PATCH] crypto: inside-secure/eip93 - unregister only available algorithm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <546d3fae-15ea-4614-8bae-90e7207fb399@wp.pl>
Date: Sat, 10 Jan 2026 18:24:10 +0100
From: Aleksander Jan Bajkowski <olek2@...pl>
To: Antoine Tenart <atenart@...nel.org>
Cc: ansuelsmth@...il.com, herbert@...dor.apana.org.au, davem@...emloft.net,
 vschagen@...oud.com, linux-crypto@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: inside-secure/eip93 - unregister only available
 algorithm

Hi Antoine,

On 1/5/26 16:01, Antoine Tenart wrote:
> On Wed, Dec 31, 2025 at 12:51:57AM +0100, Aleksander Jan Bajkowski wrote:
>> EIP93 has an options register. This register indicates which crypto
>> algorithms are implemented in silicon. Supported algorithms are
>> registered on this basis. Unregister algorithms on the same basis.
>> Currently, all algorithms are unregistered, even those not supported
>> by HW. This results in panic on platforms that don't have all options
>> implemented in silicon.
>>
>> Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support")
>> Signed-off-by: Aleksander Jan Bajkowski <olek2@...pl>
>> ---
>>   .../crypto/inside-secure/eip93/eip93-main.c   | 107 ++++++++++--------
>>   1 file changed, 61 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/crypto/inside-secure/eip93/eip93-main.c b/drivers/crypto/inside-secure/eip93/eip93-main.c
>> index 3cdc3308dcac..dfac2b23e2d9 100644
>> --- a/drivers/crypto/inside-secure/eip93/eip93-main.c
>> +++ b/drivers/crypto/inside-secure/eip93/eip93-main.c
>> @@ -77,11 +77,65 @@ inline void eip93_irq_clear(struct eip93_device *eip93, u32 mask)
>>   	__raw_writel(mask, eip93->base + EIP93_REG_INT_CLR);
>>   }
>>   
>> -static void eip93_unregister_algs(unsigned int i)
>> +static int eip93_algo_is_supported(struct eip93_alg_template *eip93_algo,
>> +				   u32 supported_algo_flags)
>> +{
>> +	u32 alg_flags = eip93_algo->flags;
>> +
>> +	if ((IS_DES(alg_flags) || IS_3DES(alg_flags)) &&
>> +	    !(supported_algo_flags & EIP93_PE_OPTION_TDES))
>> +		return 0;
>> +
>> +	if (IS_AES(alg_flags)) {
>> +		if (!(supported_algo_flags & EIP93_PE_OPTION_AES))
>> +			return 0;
>> +
>> +		if (!IS_HMAC(alg_flags)) {
>> +			if (supported_algo_flags & EIP93_PE_OPTION_AES_KEY128)
>> +				eip93_algo->alg.skcipher.max_keysize =
>> +					AES_KEYSIZE_128;
>> +
>> +			if (supported_algo_flags & EIP93_PE_OPTION_AES_KEY192)
>> +				eip93_algo->alg.skcipher.max_keysize =
>> +					AES_KEYSIZE_192;
>> +
>> +			if (supported_algo_flags & EIP93_PE_OPTION_AES_KEY256)
>> +				eip93_algo->alg.skcipher.max_keysize =
>> +					AES_KEYSIZE_256;
>> +
>> +			if (IS_RFC3686(alg_flags))
>> +				eip93_algo->alg.skcipher.max_keysize +=
>> +					CTR_RFC3686_NONCE_SIZE;
> Shouldn't the keysize assignment parts be kept in eip93_register_algs as
> this has nothing to do with checking if an alg is supported and as
> there's no point setting those (again) in the unregistration path?
>
You're right. I'll fix this in v2.


Regards,
Aleksander