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.
Reported-by: larryw3i larryw3i@yeah.net Closes: https://lore.kernel.org/r/3af01fec-b4d3-4d0c-9450-2b722d4bbe39@yeah.net/ Closes: https://lists.debian.org/debian-kernel/2025/09/msg00019.html Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113996 Cc: stable@vger.kernel.org Cc: AlanSong-oc@zhaoxin.com Cc: CobeChen@zhaoxin.com Cc: GeorgeXue@zhaoxin.com Cc: HansHu@zhaoxin.com Cc: LeoLiu-oc@zhaoxin.com Cc: TonyWWang-oc@zhaoxin.com Cc: YunShen@zhaoxin.com Signed-off-by: Eric Biggers ebiggers@kernel.org ---
This patch is targeting crypto/master
drivers/crypto/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
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 select CRYPTO_HASH select CRYPTO_SHA1 select CRYPTO_SHA256 help Use VIA PadLock for SHA1/SHA256 algorithms.
base-commit: 59b0afd01b2ce353ab422ea9c8375b03db313a21
On 11/17/2025 2:39 AM, 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.
Following Herbert Xu's suggestion（https://lore.kernel.org/linux-crypto/aFkdNoQFmr8-x4cu@gondor.apana.org.au/%E..., we have prepared a new version of the patch to address this issue. Since the code needs to remain compatible with older platforms, we are still conducting extensive testing. Once the testing is complete, I will submit the finalized patch immediately.
Best Regards AlanSong-oc
On 11/17/25 17:03, AlanSong-oc wrote:
I will submit the finalized patch immediately.
Dear AlanSong-oc,
I also want to nag a few more words. I think after a period of time, most of your machines without external graphics cards may not be able to install Debian properly (I don't know if KX-7000 is the same). It seems that GNOME 49 no longer uses X11 by default but Wayland. However, as far as I know, Wayland requires a graphics card driver to work. I have over ten laptops with your CPUs built-in here. The operating system I installed is Debian testing, but now GNOME is not working and I have to use XFCE4. 😭
Regards,
larryw3i
On 11/17/2025 6:08 PM, larryw3i wrote:
On 11/17/25 17:03, AlanSong-oc wrote:
I will submit the finalized patch immediately.
Dear AlanSong-oc,
I also want to nag a few more words. I think after a period of time, most of your machines without external graphics cards may not be able to install Debian properly (I don't know if KX-7000 is the same). It seems that GNOME 49 no longer uses X11 by default but Wayland. However, as far as I know, Wayland requires a graphics card driver to work. I have over ten laptops with your CPUs built-in here. The operating system I installed is Debian testing, but now GNOME is not working and I have to use XFCE4. 😭
Thank you for reporting the issue on the Zhaoxin platform. However, I would suggest not discussing the unrelated display problem in this patch email. Regarding the display issue you encountered, as far as I know, using Wayland for display does not require a dedicated graphics driver. Wayland can operate using the generic SimpleDRM driver. However, I have not checked whether SimpleDRM is enabled or available in Debian. If you need the proper graphics driver for the Zhaoxin platform, I recommend contacting the OEM or Zhaoxin customer support.
Best Regards AlanSong-oc
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.
Thanks,
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?
- Eric
On 12/17/2025 12:56 PM, Herbert Xu wrote:
On Wed, Dec 17, 2025 at 12:30:57PM +0800, AlanSong-oc wrote:
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?
Perhaps it would be easier if you just added Zhaoxin support to lib/crypto instead?
Sincere thanks for your helpful suggestion. I will add ZHAOXIN platform support to lib/crypto.
Best Regards AlanSong-oc
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
On Wed, Dec 17, 2025 at 12:30:57PM +0800, AlanSong-oc wrote:
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?
Perhaps it would be easier if you just added Zhaoxin support to lib/crypto instead?
Cheers,
linux-stable-mirror@lists.linaro.org
-
AlanSong-oc -
Eric Biggers -
Herbert Xu -
larryw3i