Re: [PATCH] crypto: padlock-sha - Disable broken driver

From: AlanSong-oc
Date: Tue Dec 16 2025 - 23:56:59 EST



On 11/18/2025 12:02 PM, Eric Biggers wrote:
> On Tue, Nov 18, 2025 at 11:34:50AM +0800, Herbert Xu wrote:
>> On Sun, Nov 16, 2025 at 10:39:26AM -0800, Eric Biggers wrote:
>>> This driver is known broken, as it computes the wrong SHA-1 and SHA-256
>>> hashes. Correctness needs to be the first priority for cryptographic
>>> code. Just disable it, allowing the standard (and actually correct)
>>> SHA-1 and SHA-256 implementations to take priority.
>>
>> ...
>>
>>> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
>>> index a6688d54984c..16ea3e741350 100644
>>> --- a/drivers/crypto/Kconfig
>>> +++ b/drivers/crypto/Kconfig
>>> @@ -38,11 +38,11 @@ config CRYPTO_DEV_PADLOCK_AES
>>> If unsure say M. The compiled module will be
>>> called padlock-aes.
>>>
>>> config CRYPTO_DEV_PADLOCK_SHA
>>> tristate "PadLock driver for SHA1 and SHA256 algorithms"
>>> - depends on CRYPTO_DEV_PADLOCK
>>> + depends on CRYPTO_DEV_PADLOCK && BROKEN
>>
>> It's only broken on ZHAOXIN, so this should be conditional on
>> CPU_SUP_ZHAOXIN.
>>
>
> I.e., it's apparently broken on at least every CPU that has this
> hardware that's been released in the last 14 years. How confident are
> you that it still works on VIA CPUs from 2011 and earlier and is worth
> maintaining for them?

Given the lack of a verification platform for the current padlock-sha
driver, and the fact that these CPUs are rarely used today, extending
the existing padlock-sha driver to support the ZHAOXIN platform is very
difficult. To address the issues encountered when using the padlock-sha
driver on the ZHAOXIN platform, would it be acceptable to submit a
completely new driver that aligns with the previous advice?

Best Regards
AlanSong-oc