* Re: [PATCH 1/3] dt-bindings: crypto: qcom-qce: Document the Shikra crypto engine
From: Krzysztof Kozlowski @ 2026-05-15 11:00 UTC (permalink / raw)
To: Kuldeep Singh, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Vinod Koul, Frank Li, Andy Gross
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel, dmaengine
In-Reply-To: <20260515-shikra_qcrypto-v1-1-80f07b345c29@oss.qualcomm.com>
On 14/05/2026 21:23, Kuldeep Singh wrote:
> Document the crypto engine on the Shikra platform.
>
> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> ---
Same comments as for IPQ, Nord. I gave the same feedback internally more
than once.
NAK
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: qcom: shikra: Enable ice support for SDHC
From: Kuldeep Singh @ 2026-05-15 10:46 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Kuldeep Singh
In-Reply-To: <20260515-shikra_ice_ufs-v2-0-2724a54339db@oss.qualcomm.com>
Add Inline Crypto Engine (ICE) node for Shikra and connect it to the
SDHC controller via qcom,ice phandle. This allows the SDHC controller to
use hardware inline encryption.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index 262c488add1e..0b988dd607df 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -641,6 +641,7 @@ &mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
mmc-hs400-enhanced-strobe;
resets = <&gcc GCC_SDCC1_BCR>;
+ qcom,ice = <&sdhc_ice>;
status = "disabled";
@@ -663,6 +664,17 @@ opp-384000000 {
};
};
+ sdhc_ice: crypto@4748000 {
+ compatible = "qcom,shikra-inline-crypto-engine",
+ "qcom,inline-crypto-engine";
+ reg = <0x0 0x04748000 0x0 0x18000>;
+ clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>,
+ <&gcc GCC_SDCC1_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&rpmpd RPMHPD_CX>;
+ };
+
qupv3_0: geniqup@4ac0000 {
compatible = "qcom,geni-se-qup";
reg = <0x0 0x04ac0000 0x0 0x2000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: crypto: qcom,inline-crypto-engine: Document Shikra ICE
From: Kuldeep Singh @ 2026-05-15 10:46 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Kuldeep Singh
In-Reply-To: <20260515-shikra_ice_ufs-v2-0-2724a54339db@oss.qualcomm.com>
Document the Inline Crypto Engine (ICE) on the Shikra platform.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
index ccb6b8dd8e11..c0b083da78bf 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
@@ -20,6 +20,7 @@ properties:
- qcom,sa8775p-inline-crypto-engine
- qcom,sc7180-inline-crypto-engine
- qcom,sc7280-inline-crypto-engine
+ - qcom,shikra-inline-crypto-engine
- qcom,sm8450-inline-crypto-engine
- qcom,sm8550-inline-crypto-engine
- qcom,sm8650-inline-crypto-engine
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] Add support for ice sdhc on shikra
From: Kuldeep Singh @ 2026-05-15 10:46 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Kuldeep Singh
This patchseries attempt to enable ice sdhc on shikra similar to other
platforms.
Validations:
- Driver probe on bootup.
Dependency on:
- https://lore.kernel.org/all/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com/
- https://lore.kernel.org/linux-arm-msm/20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com/
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Changes in v2:
- Reword commit message for patch 2/2 and cover letter.
- Link to v1: https://patch.msgid.link/20260515-shikra_ice_ufs-v1-0-b1b6ced70559@oss.qualcomm.com
---
Kuldeep Singh (2):
dt-bindings: crypto: qcom,inline-crypto-engine: Document Shikra ICE
arm64: dts: qcom: shikra: Enable ice support for SDHC
.../bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
arch/arm64/boot/dts/qcom/shikra.dtsi | 12 ++++++++++++
2 files changed, 13 insertions(+)
---
base-commit: 7e247866bbe72314f68036d5171c1af354ccdbe8
change-id: 20260513-shikra_ice_ufs-59d0a42e3482
Best regards,
--
Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 0/2] authencesn: Refactor in-place decryption
From: Scott Guo @ 2026-05-15 10:41 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, Scott GUO
In-Reply-To: <20260515083645.4024574-1-scott_gzh@163.com>
BTW, this should fix the Fragnesia vulnerability.
在 2026/5/15 16:36, scott_gzh@163.com 写道:
> From: Scott GUO <scottzhguo@tencent.com>
>
> This patch set introduced the sglist_shift_{left,right} helper
> and refactor the sequence number handling for authencesn
> decryption. Avoiding write to the auth part of the sg list.
>
> Scott GUO (2):
> scatterlist: Introduce sglist_shift_{left,right} helpers
> authencesn: Refactor inplace-decryption with sglist shift helper
>
> crypto/authencesn.c | 38 ++++++-----------
> crypto/scatterwalk.c | 79 ++++++++++++++++++++++++++++++++++++
> include/crypto/scatterwalk.h | 6 +++
> 3 files changed, 97 insertions(+), 26 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] X.509: Fix validation of ASN.1 certificate header
From: Alistair Francis @ 2026-05-15 10:37 UTC (permalink / raw)
To: Lukas Wunner
Cc: Herbert Xu, David S. Miller, David Howells, Ignat Korchagin,
keyrings, linux-crypto
In-Reply-To: <782bc59d5939aa69b58cad42f71946f1c0a6dccb.1778741457.git.lukas@wunner.de>
On Thu, May 14, 2026 at 4:57 PM Lukas Wunner <lukas@wunner.de> wrote:
>
> x509_load_certificate_list() seeks to enforce that a certificate starts
> with 0x30 0x82 (ASN.1 SEQUENCE tag followed by a length of more than 256
> and less than 65535 bytes).
>
> But it only enforces that *either* of those two byte values are present,
> instead of checking for the *conjunction* of the two values. Fix it.
>
> Fixes: 631cc66eb9ea ("MODSIGN: Provide module signing public keys to the kernel")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/r/20260508033917.B5873C2BCB0@smtp.kernel.org/
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: stable@vger.kernel.org # v3.7+
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
> crypto/asymmetric_keys/x509_loader.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/crypto/asymmetric_keys/x509_loader.c b/crypto/asymmetric_keys/x509_loader.c
> index a417413..0d516c7 100644
> --- a/crypto/asymmetric_keys/x509_loader.c
> +++ b/crypto/asymmetric_keys/x509_loader.c
> @@ -20,7 +20,7 @@ int x509_load_certificate_list(const u8 cert_list[],
> */
> if (end - p < 4)
> goto dodgy_cert;
> - if (p[0] != 0x30 &&
> + if (p[0] != 0x30 ||
> p[1] != 0x82)
> goto dodgy_cert;
> plen = (p[2] << 8) | p[3];
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: shikra: Add qcrypto node support
From: Konrad Dybcio @ 2026-05-15 10:28 UTC (permalink / raw)
To: Kuldeep Singh, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Vinod Koul, Frank Li, Andy Gross
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel, dmaengine
In-Reply-To: <20260515-shikra_qcrypto-v1-3-80f07b345c29@oss.qualcomm.com>
On 5/14/26 9:23 PM, Kuldeep Singh wrote:
> Add qcrypto and cryptobam support for shikra target.
>
> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index 262c488add1e..dbac0e901d6e 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -541,6 +541,41 @@ config_noc: interconnect@1900000 {
> #interconnect-cells = <2>;
> };
>
> + cryptobam: dma-controller@1b04000 {
> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
> + reg = <0x0 0x01b04000 0x0 0x24000>;
> + interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>;
> + #dma-cells = <1>;
> + iommus = <&apps_smmu 0x84 0x0011>,
> + <&apps_smmu 0x86 0x0011>,
> + <&apps_smmu 0x92 0x0>,
> + <&apps_smmu 0x94 0x0011>,
> + <&apps_smmu 0x96 0x0011>,
These two entries are logically the same (SID & ~mask) as the first two,
does it still work if you remove them?
> + <&apps_smmu 0x98 0x0001>,
> + <&apps_smmu 0x9F 0x0>;
Let's keep lowercase hex
Konrad
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: shikra: Enable ice support
From: Kuldeep Singh @ 2026-05-15 10:28 UTC (permalink / raw)
To: Konrad Dybcio, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel
In-Reply-To: <8ed6604f-f959-4b20-8b23-ded130426f36@oss.qualcomm.com>
On 15-05-2026 15:54, Konrad Dybcio wrote:
> On 5/14/26 10:30 PM, Kuldeep Singh wrote:
>> Add UFS inline crypto engine(ICE) support for shikra.
>
> s/ufs/SDCC
My bad! Thanks for pointing.
I leveraged commit message and made this mistake.
Will send v2 with updated commit message.
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v2] crypto: krb5 - filter out async aead implementations at alloc
From: Herbert Xu @ 2026-05-15 10:27 UTC (permalink / raw)
To: Michael Bommarito
Cc: David Howells, David S. Miller, linux-crypto, Eric Biggers,
Marc Dionne, linux-afs, Ilya Dryomov, Xiubo Li, ceph-devel,
stable, linux-kernel
In-Reply-To: <20260510232455.2245650-1-michael.bommarito@gmail.com>
On Sun, May 10, 2026 at 07:24:55PM -0400, Michael Bommarito wrote:
> krb5_aead_encrypt(), krb5_aead_decrypt() in rfc3961_simplified.c and
> rfc8009_encrypt(), rfc8009_decrypt() in rfc8009_aes2.c set a NULL
> completion callback and treat any negative return from
> crypto_aead_{encrypt,decrypt}() as terminal, falling through to
> kfree_sensitive(buffer). When the encrypt_name resolves to an
> async AEAD instance the request returns -EINPROGRESS, the buffer
> is freed while the backend's worker still holds a pointer, and the
> worker dereferences the freed slab on completion.
>
> KASAN report under UML+SLUB with a synthetic async aead backend
> bound to krb5->encrypt_name:
>
> BUG: KASAN: slab-use-after-free in t5_stub_complete+0x7d/0xc7
>
> The helpers were written synchronously, so filter the async
> instances out at allocation time instead of plumbing
> crypto_wait_req() through every call site.
>
> Reachable via net/rxrpc/rxgk.c, fs/afs/cm_security.c and
> net/ceph/crypto.c on systems with an async AEAD provider bound to
> the krb5 enctype name.
>
> Fixes: 00244da40f78 ("crypto/krb5: Implement the Kerberos5 rfc3961 encrypt and decrypt functions")
> Fixes: 6c3c0e86c2ac ("crypto/krb5: Implement the AES enctypes from rfc8009")
> Cc: stable@vger.kernel.org
> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> crypto/krb5/krb5_api.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: crypto: qcom,prng: Document TRNG on Nord SoC
From: Herbert Xu @ 2026-05-15 10:25 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, linux-crypto,
devicetree, linux-kernel
In-Reply-To: <20260510021809.1130114-1-shengchao.guo@oss.qualcomm.com>
On Sun, May 10, 2026 at 10:18:09AM +0800, Shawn Guo wrote:
> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>
> Document True Random Number Generator on Qualcomm Nord SoC.
>
> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> Changes in v3:
> - Improve commit log to drop "compatible with qcom,trng" part
> - Link to v2 (TRNG): https://lore.kernel.org/all/20260427012308.231350-1-shengchao.guo@oss.qualcomm.com/
>
> Changes in v2:
> - Improve commit log to make the compatibility explicit
> - Add missing SoB
> - Link to v1: https://lore.kernel.org/all/20260420025732.1240525-1-shengchao.guo@oss.qualcomm.com/
>
> Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 1 +
> 1 file changed, 1 insertion(+)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/2] crypto: atmel-sha204a - drop __maybe_unused and of_match_ptr
From: Herbert Xu @ 2026-05-15 10:25 UTC (permalink / raw)
To: Thorsten Blum
Cc: David S. Miller, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260509101155.2095-3-thorsten.blum@linux.dev>
On Sat, May 09, 2026 at 12:11:55PM +0200, Thorsten Blum wrote:
> Since MODULE_DEVICE_TABLE() keeps atmel_sha204a_dt_ids referenced, drop
> the unnecessary __maybe_unused annotation. Also remove of_match_ptr()
> because OF matching is stubbed out when CONFIG_OF=n.
>
> Reformat atmel_sha204a_dt_ids to silence a checkpatch error and
> atmel_sha204a_id for consistency.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/atmel-sha204a.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: shikra: Enable ice support
From: Konrad Dybcio @ 2026-05-15 10:24 UTC (permalink / raw)
To: Kuldeep Singh, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260515-shikra_ice_ufs-v1-2-b1b6ced70559@oss.qualcomm.com>
On 5/14/26 10:30 PM, Kuldeep Singh wrote:
> Add UFS inline crypto engine(ICE) support for shikra.
s/ufs/SDCC
Konrad
^ permalink raw reply
* Re: [PATCH] crypto: use designated initializers for report structs
From: Herbert Xu @ 2026-05-15 10:24 UTC (permalink / raw)
To: Thorsten Blum; +Cc: David S. Miller, linux-crypto, linux-kernel
In-Reply-To: <20260508105717.472043-3-thorsten.blum@linux.dev>
On Fri, May 08, 2026 at 12:57:17PM +0200, Thorsten Blum wrote:
> Use designated initializers for the report structs instead of clearing
> the struct with memset() and then copying fixed strings with strscpy()
> at runtime.
>
> This keeps the structs zero-initialized, lets the compiler diagnose
> oversized string literals, and makes the code easier to read.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> crypto/acompress.c | 8 +++-----
> crypto/aead.c | 10 ++++------
> crypto/ahash.c | 8 +++-----
> crypto/akcipher.c | 8 +++-----
> crypto/crypto_user.c | 14 ++++++--------
> crypto/kpp.c | 8 +++-----
> crypto/lskcipher.c | 10 ++++------
> crypto/rng.c | 8 +++-----
> crypto/scompress.c | 8 +++-----
> crypto/shash.c | 8 +++-----
> crypto/sig.c | 6 +++---
> crypto/skcipher.c | 10 ++++------
> 12 files changed, 42 insertions(+), 64 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: shikra: Enable ice support
From: Konrad Dybcio @ 2026-05-15 10:24 UTC (permalink / raw)
To: Kuldeep Singh, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260515-shikra_ice_ufs-v1-2-b1b6ced70559@oss.qualcomm.com>
On 5/14/26 10:30 PM, Kuldeep Singh wrote:
> Add UFS inline crypto engine(ICE) support for shikra.
>
> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] crypto: safexcel - Fix potential memory leak in safexcel_pci_probe()
From: Herbert Xu @ 2026-05-15 10:24 UTC (permalink / raw)
To: Abdun Nihaal; +Cc: atenart, davem, linux-crypto, linux-kernel, pvanleeuwen
In-Reply-To: <20260508090347.74176-1-nihaal@cse.iitm.ac.in>
On Fri, May 08, 2026 at 02:33:45PM +0530, Abdun Nihaal wrote:
> The memory allocated for priv in safexcel_pci_probe() is not freed in the
> error paths, as well as in the PCI remove function. Fix this by using
> device managed allocation.
>
> Fixes: 625f269a5a7a ("crypto: inside-secure - add support for PCI based FPGA development board")
> Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
> ---
> Compile tested only. Issue found using static analysis.
>
> drivers/crypto/inside-secure/safexcel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: amlogic - avoid double cleanup in meson_crypto_probe()
From: Herbert Xu @ 2026-05-15 10:23 UTC (permalink / raw)
To: Dawei Feng
Cc: clabbe, davem, linux-crypto, linux-amlogic, linux-kernel,
jianhao.xu, stable, Zilin Guan
In-Reply-To: <20260508042416.419216-1-dawei.feng@seu.edu.cn>
On Fri, May 08, 2026 at 12:24:16PM +0800, Dawei Feng wrote:
> When meson_allocate_chanlist() fails after a partial allocation, it already
> unwinds the allocated chanlist state through its local error path.
> meson_crypto_probe() then jump to error_flow and calls
> meson_free_chanlist() again, causing the same per-flow resources to be torn
> down twice. In the reproduced failure path, the second teardown
> re-entered crypto_engine_exit() on an already destroyed worker and KASAN
> reported a slab-use-after-free in kthread_destroy_worker().
>
> Prevent double-free by handling partial allocation failures locally within
> meson_allocate_chanlist() and skipping the outer cleanup path.
>
> The bug was first flagged by an experimental analysis tool we are
> developing for kernel memory-management bugs while analyzing
> v6.13-rc1. The tool is still under development and is not yet publicly
> available.
>
> The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1,
> using the reproducer under tools/testing/meson_crypto_probe. The reproducer
> forces the second dma_alloc_attrs() call in the gxl-crypto probe path to
> return NULL, making meson_allocate_chanlist() fail after partial
> initialization. On the unpatched kernel this reliably triggered a
> slab-use-after-free. With this fix applied, the same reproducer no longer
> emits any KASAN report and the probe fails cleanly with -ENOMEM.
>
> ==================================================================
> BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0
> Read of size 8 at addr ff1100010c057a68 by task insmod/265
>
> CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy)
> Tainted: [O]=OOT_MODULE
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
> Call Trace:
> <TASK>
> dump_stack_lvl+0x68/0xa0
> print_report+0xcb/0x5e0
> ? __virt_addr_valid+0x21d/0x3f0
> ? kthread_destroy_worker+0xb2/0xd0
> ? kthread_destroy_worker+0xb2/0xd0
> kasan_report+0xca/0x100
> ? kthread_destroy_worker+0xb2/0xd0
> kthread_destroy_worker+0xb2/0xd0
> meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto]
> platform_probe+0x99/0x140
> really_probe+0x1c6/0x6a0
> ? __pfx___device_attach_driver+0x10/0x10
> __driver_probe_device+0x248/0x310
> ? acpi_driver_match_device+0xb0/0x100
> driver_probe_device+0x48/0x210
> ? __pfx___device_attach_driver+0x10/0x10
> __device_attach_driver+0x160/0x320
> bus_for_each_drv+0x104/0x190
> ? __pfx_bus_for_each_drv+0x10/0x10
> ? _raw_spin_unlock_irqrestore+0x2c/0x50
> __device_attach+0x19d/0x3b0
> ? __pfx___device_attach+0x10/0x10
> ? do_raw_spin_unlock+0x53/0x220
> device_initial_probe+0x78/0xa0
> bus_probe_device+0x5b/0x130
> device_add+0xcfd/0x1430
> ? __pfx_device_add+0x10/0x10
> ? insert_resource+0x34/0x50
> ? lock_release+0xc9/0x290
> platform_device_add+0x24e/0x590
> ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro]
> meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro]
> do_one_initcall+0xc0/0x450
> ? __pfx_do_one_initcall+0x10/0x10
> ? _raw_spin_unlock_irqrestore+0x2c/0x50
> ? __create_object+0x59/0x80
> ? kasan_unpoison+0x27/0x60
> do_init_module+0x27b/0x7d0
> ? __pfx_do_init_module+0x10/0x10
> ? kasan_quarantine_put+0x84/0x1d0
> ? kfree+0x32c/0x510
> ? load_module+0x561e/0x5ff0
> load_module+0x54fe/0x5ff0
> ? __pfx_load_module+0x10/0x10
> ? security_file_permission+0x20/0x40
> ? kernel_read_file+0x23d/0x6e0
> ? mmap_region+0x235/0x4a0
> ? __pfx_kernel_read_file+0x10/0x10
> ? __file_has_perm+0x2c0/0x3e0
> init_module_from_file+0x158/0x180
> ? __pfx_init_module_from_file+0x10/0x10
> ? __lock_acquire+0x45a/0x1ba0
> ? idempotent_init_module+0x315/0x610
> ? lock_release+0xc9/0x290
> ? lockdep_init_map_type+0x4b/0x220
> ? do_raw_spin_unlock+0x53/0x220
> idempotent_init_module+0x330/0x610
> ? __pfx_idempotent_init_module+0x10/0x10
> ? __pfx_cred_has_capability.isra.0+0x10/0x10
> ? ksys_mmap_pgoff+0x385/0x520
> __x64_sys_finit_module+0xbe/0x120
> do_syscall_64+0x115/0x690
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f7d6d31690d
> Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f3 b4 0f 00 f7 d8 >
> RSP: 002b:00007fffc027ac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> RAX: ffffffffffffffda RBX: 000055f7b81967c0 RCX: 00007f7d6d31690d
> RDX: 0000000000000000 RSI: 000055f79a0d6cd2 RDI: 0000000000000003
> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000003 R11: 0000000000000246 R12: 000055f79a0d6cd2
> R13: 000055f7b8196790 R14: 000055f79a0d5888 R15: 000055f7b81968e0
> </TASK>
>
> Fixes: 48fe583fe541 ("crypto: amlogic - Add crypto accelerator for amlogic GXL")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
> ---
> drivers/crypto/amlogic/amlogic-gxl-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3 00/11] crypto: talitos - fix several issues in the Freescale talitos crypto driver
From: Herbert Xu @ 2026-05-15 10:23 UTC (permalink / raw)
To: Paul Louvel
Cc: David S. Miller, Paolo Abeni, David Howells, Kim Phillips,
Christophe Leroy, linux-crypto, linux-kernel, Thomas Petazzoni,
Herve Codina, stable
In-Reply-To: <20260507-bootlin_test-7-1-rc1_sec_bugfix-v3-0-c98d7589b942@bootlin.com>
On Thu, May 07, 2026 at 04:41:46PM +0200, Paul Louvel wrote:
> This series fixes several issues in the Freescale talitos crypto driver.
>
> Patch 1 fixes a missing dma_sync_single_for_cpu() before reading a
> descriptor header.
>
> Patches 2-5 add support for chaining an arbitrary number of descriptors
> in the driver for the SEC1 hardware.
>
> Patches 6-8 rework the SEC1 hash implementation to build descriptor
> chains instead of submitting one descriptor at a time via a workqueue.
>
> Patches 9-10 are cleanups: rename first_desc/last_desc to
> first_request/last_request, and remove a useless wrapper function.
>
> Patch 11 fixes the same ahash request size limitation on SEC2 (64k - 1
> bytes), by splitting ahash_done() into SEC1 and SEC2 paths so that SEC2
> iterates through descriptors sequentially.
>
> Tested on an MPC885 SoC (SEC1 Lite), and on an MPC8321EMP SoC (SEC2)
> with CRYPTO_SELFTESTS_FULL=y.
> For the SEC1 Lite, some tests are failing due to a timeout waiting for
> request completion. These failed tests existed prior to this series.
> On SEC2, there is no failed tests.
>
> Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
> ---
> Changes in v3:
> - Patch 1 was reading the next chained descriptor header
> unconditionally. Fixed it by checking if a request actually contained
> a chained descriptor before deferencing it.
> - For descriptor chaining introduced in patch 2, use a next pointer
> embedded inside struct talitos_edesc instead of the kernel's struct
> list_node. This removes the necessity for a desc_chain member in
> struct talitos_request. A dirty hack was previously used to assign a
> request->desc_chain to the current request by taking edesc->prev,
> assuming that the descriptor was added to a list before calling
> talitos_submit(). Not only was this non-idiomatic, but it also broke
> the skcipher and aead implementations because they do not use the
> descriptor chaining feature at all. The descriptor chaining mechanism
> does not need a doubly circular linked list; this change makes the
> code more readable than sticking with the kernel linked list
> implementation.
> - Updated the performance measurement in patch 6.
> - Drop patch 12, which was a revert of commit 4b24ea971a93 ("crypto:
> talitos - Preempt overflow interrupts off-by-one fix"). This patch was
> primarily motivated because the SEC1 has a Fetch Register rather than
> a Fetch FIFO per channel. As a result, having a value of 24 in the
> device tree node for the channel-fifo-len property does not make
> sense, as the hardware does not have a Fetch FIFO. Setting this value
> to 1 (which should be the correct value for SoCs featuring the SEC1
> engine family) breaks the driver because no descriptor can be
> submitted due to commit 4b24ea971a93, and the patch was primarily
> intended to fix this issue. As this issue is too deep to be addressed
> in this patch series, it has been dropped.
> - Link to v2: https://patch.msgid.link/20260505-bootlin_test-7-1-rc1_sec_bugfix-v2-0-5818064bd190@bootlin.com
>
> Changes in v2:
> - Split the first patch into smaller, logically separated patches for
> easier review.
> - Added more context on testing on the cover letter.
> - Introduce a fix to correctly read hardware descriptor header. This fix
> was motivated by a remark of Sashiko on the v1:
> https://sashiko.dev/#/patchset/20260504-bootlin_test-7-1-rc1_sec_bugfix-v1-0-c97c641976f5%40bootlin.com
> - Separate SEC2 64k-1 ahash limitation fix into its own patch.
> - Link to v1: https://patch.msgid.link/20260504-bootlin_test-7-1-rc1_sec_bugfix-v1-0-c97c641976f5@bootlin.com
>
> To: Herbert Xu <herbert@gondor.apana.org.au>
> To: "David S. Miller" <davem@davemloft.net>
> To: Christophe Leroy <chleroy@kernel.org>
> To: Paolo Abeni <pabeni@redhat.com>
> To: David Howells <dhowells@redhat.com>
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
> Paul Louvel (11):
> crypto: talitos - use dma_sync_single_for_cpu() before reading descriptor header
> crypto: talitos - add chaining of arbitrary number of descriptor for the SEC1
> crypto: talitos - move dma unmapping code in flush_channel() into a standalone dma_unmap_request() function
> crypto: talitos - move dma mapping code in talitos_submit() into a standalone dma_map_request() function
> crypto: talitos - move code in current_desc_hdr() into a standalone function
> crypto: talitos/hash - prepare SEC1 descriptor chaining, remove additional descriptor
> crypto: talitos/hash - use descriptor chaining for SEC1 instead of workqueue
> crypto: talitos/hash - drop workqueue mechanism for SEC1
> crypto: talitos/hash - rename first_desc/last_desc to first_request/last_request
> crypto: talitos/hash - remove useless wrapper
> crypto: talitos/hash - fix SEC2 64k - 1 ahash request limitation
>
> drivers/crypto/talitos.c | 549 ++++++++++++++++++++++++-----------------------
> drivers/crypto/talitos.h | 12 ++
> 2 files changed, 287 insertions(+), 274 deletions(-)
> ---
> base-commit: db8b9f227833e729faf44a512aa1e88a625b5ad8
> change-id: 20260504-bootlin_test-7-1-rc1_sec_bugfix-13169ed07ddc
>
> Best regards,
> --
> Paul Louvel <paul.louvel@bootlin.com>
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] talitos: use devm_platform_ioremap_resource()
From: Herbert Xu @ 2026-05-15 10:23 UTC (permalink / raw)
To: Rosen Penev; +Cc: linux-crypto, David S. Miller, open list
In-Reply-To: <20260507234416.677882-1-rosenp@gmail.com>
On Thu, May 07, 2026 at 04:44:16PM -0700, Rosen Penev wrote:
> platform_get_resource and devm_ioremap effectively open codes this.
>
> The return type of devm_platform_ioremap_resource() is also nice as it
> has multiple errors that it can return.
>
> Because it internally calls devm_request_mem_region(), reg values and
> sizes cannot overlap. This was manually verified to be the case for all
> talitos users.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/crypto/talitos.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: atmel-ecc - replace min_t with min
From: Herbert Xu @ 2026-05-15 10:23 UTC (permalink / raw)
To: Thorsten Blum
Cc: David S. Miller, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260507135525.331107-3-thorsten.blum@linux.dev>
On Thu, May 07, 2026 at 03:55:27PM +0200, Thorsten Blum wrote:
> Use the simpler min() macro since the values are all unsigned and
> compatible.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/atmel-ecc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] crypto: ccp: sev-dev-tsm: bail out early when pdev->bus is NULL
From: Herbert Xu @ 2026-05-15 10:22 UTC (permalink / raw)
To: Stepan Ionichev
Cc: ashish.kalra, thomas.lendacky, aik, john.allen, davem,
linux-crypto, linux-kernel
In-Reply-To: <20260507140608.8612-1-sozdayvek@gmail.com>
On Thu, May 07, 2026 at 07:06:08PM +0500, Stepan Ionichev wrote:
> dsm_create() initially checks pdev->bus when computing segment_id:
>
> u8 segment_id = pdev->bus ? pci_domain_nr(pdev->bus) : 0;
>
> But the next two lines unconditionally dereference pdev->bus via
> pcie_find_root_port() and especially pci_dev_id(pdev), which expands
> to PCI_DEVID(dev->bus->number, dev->devfn). If pdev->bus is in fact
> NULL, segment_id is initialised to 0 but the very next statement
> crashes the kernel.
>
> smatch flags this:
>
> drivers/crypto/ccp/sev-dev-tsm.c:253 dsm_create() error: we
> previously assumed 'pdev->bus' could be null (see line 251)
>
> Make the NULL handling consistent: if pdev->bus is NULL the device
> has no PCI context to work with and SEV TIO setup cannot proceed,
> so return -ENODEV before any of the bus-dependent lookups. The
> remaining initialisation now runs only on the path where pdev->bus
> is known to be valid.
>
> No change for callers where pdev->bus is non-NULL, which is the
> only case where dsm_create() did meaningful work before this change.
>
> Fixes: 4be423572da1 ("crypto/ccp: Implement SEV-TIO PCIe IDE (phase1)")
> Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com>
> ---
> v2:
> - Add Fixes: tag (suggested by Tom Lendacky).
> - Cc Alexey Kardashevskiy (original author of the SEV-TIO code).
>
> drivers/crypto/ccp/sev-dev-tsm.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y
From: Herbert Xu @ 2026-05-15 10:21 UTC (permalink / raw)
To: Lukas Wunner
Cc: David S. Miller, Andrew Morton, Arnd Bergmann, Andrey Ryabinin,
Ignat Korchagin, Stefan Berger, linux-crypto, linux-kernel,
kasan-dev, Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andy Shevchenko, Eric Biggers,
Nathan Chancellor, David Laight, Jason A. Donenfeld,
Ard Biesheuvel
In-Reply-To: <7e3d64a53efb28740b32d1f934e78c10086208ab.1778073318.git.lukas@wunner.de>
On Wed, May 06, 2026 at 03:27:49PM +0200, Lukas Wunner wrote:
> Andrew reports build breakage of arm allmodconfig, reproducible with gcc
> 14.2.0 and 15.2.0:
>
> crypto/ecc.c: In function 'ecc_point_mult':
> crypto/ecc.c:1380:1: error: the frame size of 1360 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
>
> gcc aggressively inlines functions called by ecc_point_mult() (without
> there being any explicit inline declarations), which pushes stack usage
> close to the limit imposed by CONFIG_FRAME_WARN. allmodconfig implies
> CONFIG_KASAN_STACK=y, which increases the stack above that limit.
>
> In the bugzilla entry linked below, gcc maintainers explain that gcc
> estimates extra stack usage caused by inlining, but ASAN instrumentation
> is added in post-IPA passes and thus the inlining heuristics cannot
> account for it.
>
> It could be argued that -Werror=frame-larger-than=1280 instructs the
> compiler to avoid inlining beyond that limit lest the build breaks,
> which would imply gcc behaves incorrectly. But gcc maintainers reject
> this notion and believe that a warning switch should never affect code
> generation, even if it is promoted to an error.
>
> One way to unbreak the build is to limit inlining via -finline-limit=100
> or by explicitly declaring some functions noinline. However while it
> does keep stack usage of individual functions below the limit, *total*
> stack usage increases.
>
> A longterm solution is to refactor ecc.c for reduced stack usage. It
> currently performs ECC point multiplication with a Montgomery ladder
> which uses co-Z (conjugate) addition to trade off memory for speed.
> The algorithm is susceptible to timing attacks and needs to be replaced
> with a constant time Montgomery ladder, which should consume less memory
> and thus resolve the stack usage issue as a side effect.
>
> In the interim, raise the limit for ecc.c, as is already done for
> several other files in the source tree.
>
> Constrain to gcc because clang 19.1.7 does not exhibit the issue. It
> makes do with a 724 bytes stack frame even though it inlines almost the
> same functions as gcc.
>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124949
> Reported-by: Andrew Morton <akpm@linux-foundation.org> # off-list
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> Changes v1 -> v2:
> * s/ARCH/CONFIG_ARM/, s/LLVM/CONFIG_CC_IS_GCC/ (Nathan)
> * Add link to gcc bugzilla entry
> * Rewrite commit message to include feedback provided by gcc maintainers
> and explain high stack usage with algorithm choice
>
> Link to v1:
> https://lore.kernel.org/r/abfaede9ab2e963d784fb70598ed74935f7f8d93.1775628469.git.lukas@wunner.de/
>
> crypto/Makefile | 5 +++++
> 1 file changed, 5 insertions(+)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: artpec6 - refactor crypto_setup_out_descr for readability
From: Herbert Xu @ 2026-05-15 10:21 UTC (permalink / raw)
To: Thorsten Blum
Cc: Jesper Nilsson, Lars Persson, David S. Miller, linux-arm-kernel,
linux-crypto, linux-kernel
In-Reply-To: <20260506091627.177426-3-thorsten.blum@linux.dev>
On Wed, May 06, 2026 at 11:16:28AM +0200, Thorsten Blum wrote:
> Replace if-else with an early return to reduce code nesting, and move
> the variable declarations to the top of the function.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/axis/artpec6_crypto.c | 21 +++++++++------------
> 1 file changed, 9 insertions(+), 12 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: ccree - replace snprintf("%s") with strscpy
From: Herbert Xu @ 2026-05-15 10:21 UTC (permalink / raw)
To: Thorsten Blum
Cc: Gilad Ben-Yossef, David S. Miller, linux-crypto, linux-kernel
In-Reply-To: <20260506092150.177660-2-thorsten.blum@linux.dev>
On Wed, May 06, 2026 at 11:21:51AM +0200, Thorsten Blum wrote:
> Replace snprintf("%s") with the faster and more direct strscpy().
>
> In cc_aead.c, group the includes while at it.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/ccree/cc_aead.c | 9 ++++-----
> drivers/crypto/ccree/cc_cipher.c | 7 +++----
> drivers/crypto/ccree/cc_hash.c | 13 +++++--------
> 3 files changed, 12 insertions(+), 17 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] talitos: allocate channels with main struct
From: Herbert Xu @ 2026-05-15 10:20 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-crypto, David S. Miller, Kees Cook, Gustavo A. R. Silva,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260506085653.1211263-1-rosenp@gmail.com>
On Wed, May 06, 2026 at 01:56:53AM -0700, Rosen Penev wrote:
> Use a flexible array member to combine allocations.
>
> Add __counted_by for extra runtime analysis.
>
> Error in case of no channels as they are required.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> v2: error when no channels
> drivers/crypto/talitos.c | 19 +++++++------------
> drivers/crypto/talitos.h | 5 +++--
> 2 files changed, 10 insertions(+), 14 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: drbg - Remove support for "prediction resistance"
From: Herbert Xu @ 2026-05-15 10:20 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-kernel, Stephan Mueller, Jason A . Donenfeld,
Joachim Vandersmissen
In-Reply-To: <20260506000258.70807-1-ebiggers@kernel.org>
On Tue, May 05, 2026 at 05:02:58PM -0700, Eric Biggers wrote:
> "Prediction resistance", i.e. the property that the RNG's output is
> unpredictable even after a state compromise, might sound like a nice
> property to have. In reality, it's not very practical, as it requires
> that fresh entropy be pulled on every request. (The normal Linux RNG
> doesn't provide prediction resistance.) In the case of drbg.c, that
> means pulling from "jitterentropy", which is extremely slow.
>
> For some perspective, running a simple benchmark, generating 32 random
> bytes takes the following amount of time:
>
> get_random_bytes(): 90 ns
> drbg_nopr_hmac_sha512: 3707 ns
> drbg_pr_hmac_sha512: 773082 ns
>
> So at least in this case, the "pr" (prediction-resistant) DRBG is over
> 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or
> over 8000 times slower than the normal Linux RNG. While anyone using
> drbg.c has always had to tolerate that it's slower than the normal Linux
> RNG, the "pr" DRBG is clearly at another level of slowness.
>
> Thus, the following is also entirely unsurprising:
>
> - FIPS 140-3 doesn't actually require that SP800-90A DRBG
> implementations support prediction resistance. The non-prediction
> resistant DRBGs can be, and have been, certified.
>
> - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority
> than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already
> the one actually being used in practice.
>
> Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't
> actually useful, and it essentially just existed as another curiosity in
> the museum of crypto algorithms. Remove it to simplify the code.
>
> Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> crypto/drbg.c | 82 ++++++-------------
> crypto/testmgr.c | 21 +----
> crypto/testmgr.h | 202 -----------------------------------------------
> 3 files changed, 27 insertions(+), 278 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox