* Re: [PATCH 00/12] crypto: atmel - refactor common i2c support and add SHA256 ahash support
From: Lothar Rubusch @ 2026-05-15 20:29 UTC (permalink / raw)
To: Thorsten Blum
Cc: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <agYnpsiG8bNeVw57@linux.dev>
Hi Thorsten & ML,
On Thu, May 14, 2026 at 9:51 PM Thorsten Blum <thorsten.blum@linux.dev> wrote:
>
> Hi Lothar,
>
> On Tue, May 12, 2026 at 10:43:37PM +0000, Lothar Rubusch wrote:
> > This series restructures the Atmel secure element drivers around a
> > shared atmel-i2c core and adds SHA256 ahash support for ATSHA204A and
> > ECC based devices.
> >
> > The existing drivers duplicated substantial parts of the transport,
> > RNG, EEPROM and device management logic. This series consolidates the
> > common functionality into the shared i2c core and converts the client
> > drivers to capability based allocation.
> >
> > The series also introduces per-device timing configuration through
> > match data, moves sanity checks and RNG handling into the core driver,
> > updates workqueue handling and cleans up internal constants and helper
> > definitions.
> >
> > The final patch adds SHA256 ahash support using the hardware SHA engine
> > provided by the devices.
> >
> > ATSHA204A devices require software-side SHA256 padding according to
> > FIPS 180-4, while newer ECC devices provide a dedicated SHA final
> > command and perform padding internally in hardware.
> >
> > Supporting the SHA engine also requires changes to the command
> > transport path. SHA operations must execute as a strict uninterrupted
> > sequence consisting of SHA INIT, one or more SHA COMPUTE commands and,
> > for ECC devices, a terminating SHA FINAL command. The device loses its
> > internal SHA state if it enters sleep mode or if unrelated commands
> > are interleaved during the transaction.
> >
> > To satisfy these hardware requirements, the send/receive path is split
> > into a low-level transfer helper and a higher-level wrapper managing
> > wakeup, sleep and locking. SHA operations keep the device awake and
> > hold the i2c lock for the full duration of the hashing transaction.
> >
> > The series has been tested on ATSHA204A and ATECC508A devices.
> > Tests are ongoing/pending on ATECC608A and ATECC608B.
> > ---
> > Lothar Rubusch (12):
> > crypto: atmel - introduce shared I2C client management
> > crypto: atmel - move capability-based client allocation into i2c core
> > crypto: atmel - remove obsolete CONFIG_OF guard
> > crypto: atmel - add per-device timing and match-data driven
> > configuration
> > crypto: atmel - move RNG support into common i2c core
> > crypto: atmel - move EEPROM access support into common i2c core
> > crypto: atmel - expose CONFIG zone through sysfs
> > crypto: atmel - move device sanity check to core driver
> > crypto: atmel - check client data in remove callbacks
> > crypto: atmel - update workqueue flags and add flush on exit
> > crypto: atmel - refactor and localize driver constants
> > crypto: atmel - add SHA256 ahash support
> >
> > drivers/crypto/atmel-ecc.c | 252 +++++++-----
> > drivers/crypto/atmel-i2c.c | 679 +++++++++++++++++++++++++++++----
> > drivers/crypto/atmel-i2c.h | 180 +++++----
> > drivers/crypto/atmel-sha204a.c | 284 +++++++-------
> > 4 files changed, 1010 insertions(+), 385 deletions(-)
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
>
> Thanks, but I'm not sure reviewing such a large series is sustainable.
> I've only skimmed it, but it also mixes several different things that
> should probably be submitted separately (e.g., refactorings and new
> features).
>
No problem at all. Pls, understand my series as a proposal.
Usually I'm testing the features and use checkers. So, the series is
supposed to be functional. Anyway, there are quite some changes, which
individually need to be analyzed and well understood to get this into
"maintainable" quality, which is definitely not the case yet. I agree.
Having said that, I'd propose to separate out the first, say, 3 patches.
(AFAIK patch #3 is +/- something, you already presented, too, so I assume
it disappears by rebasing soon). I'll split up these initial patches,
do smaller steps, and come up with this series the next days.
Pls, let me know what you think. Would this be better for a review?
> Sashiko [1] also reviewed the series and found potential regressions
> that might be helpful to consider.
>
> Thanks,
> Thorsten
>
> [1] https://sashiko.dev/#/patchset/20260512224349.64621-1-l.rubusch%40gmail.com
Fascinating! Thank you so much for pointing this out!
I'll try to take sashiko comments into account. Sashiko was new to me.
I'll definitely
have a look into it, either reviews or if there is a chance to set it
up locally.
Best,
L
^ permalink raw reply
* Re: [PATCH net-next 2/5] net/rxrpc: Use local FCrypt-PCBC implementation
From: Eric Biggers @ 2026-05-15 20:14 UTC (permalink / raw)
To: David Howells
Cc: netdev, linux-afs, Marc Dionne, linux-crypto, linux-kernel,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
In-Reply-To: <287476.1778266603@warthog.procyon.org.uk>
On Fri, May 08, 2026 at 07:56:43PM +0100, David Howells wrote:
> Eric Biggers <ebiggers@kernel.org> wrote:
>
> > Also I'm waiting to see if the following patch gets merged:
> > https://lore.kernel.org/netdev/20260502211340.446927-1-n7l8m4@u.northwestern.edu/
>
> This is the favoured solution:
>
> https://lore.kernel.org/netdev/af2kdW2F1gJ9U-Gg@v4bel/
>
> The problem with the one you mentioned is that it does a mandatory copy, even
> when it doesn't need to, for rxgk. I can benchmark that to see what the
> performance impact it has.
Seems that the latest is now
https://lore.kernel.org/netdev/20260514155304.2249591-4-dhowells@redhat.com/
which is back to just using a linear buffer unconditionally. I'll
resend this series after that goes in.
- Eric
^ permalink raw reply
* Re: [GIT PULL] Crypto Fixes for 7.1
From: pr-tracker-bot @ 2026-05-15 20:10 UTC (permalink / raw)
To: Herbert Xu
Cc: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <agbpRZ1OdUC-orcg@gondor.apana.org.au>
The pull request you sent on Fri, 15 May 2026 17:37:09 +0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 tags/v7.1-p4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fd6b56615696c2addca7b43c862b21a9a386c116
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [PATCH v1] include: Remove unused crypto-ux500.h
From: Costa Shulyupin @ 2026-05-15 19:02 UTC (permalink / raw)
To: Linus Walleij, linux-kernel; +Cc: linux-crypto, Costa Shulyupin
The UX500 crypto drivers were removed in commit 453de3eb08c4
("crypto: ux500/cryp - delete driver") and commit dd7b7972cb89
("crypto: ux500/hash - delete driver"). No file includes
this header.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
---
include/linux/platform_data/crypto-ux500.h | 22 ----------------------
1 file changed, 22 deletions(-)
delete mode 100644 include/linux/platform_data/crypto-ux500.h
diff --git a/include/linux/platform_data/crypto-ux500.h b/include/linux/platform_data/crypto-ux500.h
deleted file mode 100644
index 5d43350e32cc..000000000000
--- a/include/linux/platform_data/crypto-ux500.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright (C) ST-Ericsson SA 2011
- *
- * Author: Joakim Bech <joakim.xx.bech@stericsson.com> for ST-Ericsson
- */
-#ifndef _CRYPTO_UX500_H
-#define _CRYPTO_UX500_H
-#include <linux/dmaengine.h>
-#include <linux/platform_data/dma-ste-dma40.h>
-
-struct hash_platform_data {
- void *mem_to_engine;
- bool (*dma_filter)(struct dma_chan *chan, void *filter_param);
-};
-
-struct cryp_platform_data {
- struct stedma40_chan_cfg mem_to_engine;
- struct stedma40_chan_cfg engine_to_mem;
-};
-
-#endif
--
2.53.0
^ permalink raw reply related
* [PATCH] treewide: replace /usr/bin/python3 shebangs with env python3
From: Oli R @ 2026-05-15 18:07 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Mario Limonciello, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Shuah Khan, Mathieu Desnoyers, Paul E. McKenney,
Boqun Feng, open list:DRM DRIVER for Qualcomm display hardware,
open list:DRM DRIVER for Qualcomm display hardware,
open list:DRM DRIVER for Qualcomm display hardware, open list,
open list:AMD CRYPTOGRAPHIC COPROCESSOR (CCP) DRIVER - DB...,
open list:PERFORMANCE EVENTS SUBSYSTEM,
open list:KERNEL SELFTEST FRAMEWORK
Cc: Oli R
Use /usr/bin/env python3 instead of hardcoded interpreter paths
to improve portability across environments where python3 is not
installed in /usr/bin.
No functional changes intended.
Signed-off-by: Oli R <sigmatwojastara@gmail.com>
---
| 2 +-
scripts/macro_checker.py | 2 +-
tools/crypto/ccp/dbc.py | 2 +-
tools/crypto/ccp/dbc_cli.py | 2 +-
tools/crypto/ccp/test_dbc.py | 2 +-
tools/perf/tests/shell/lib/perf_json_output_lint.py | 2 +-
.../selftests/devices/probe/test_discoverable_devices.py | 2 +-
tools/testing/selftests/rseq/rseq-slice-hist.py | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
--git a/drivers/gpu/drm/msm/registers/gen_header.py b/drivers/gpu/drm/msm/registers/gen_header.py
index 2acad951f1e2..10316f517a7d 100644
--- a/drivers/gpu/drm/msm/registers/gen_header.py
+++ b/drivers/gpu/drm/msm/registers/gen_header.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/env python3
#
# Copyright © 2019-2024 Google, Inc.
#
diff --git a/scripts/macro_checker.py b/scripts/macro_checker.py
index ba550982e98f..7dbb114a57d5 100755
--- a/scripts/macro_checker.py
+++ b/scripts/macro_checker.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/env python3
# SPDX-License-Identifier: GPL-2.0
# Author: Julian Sun <sunjunchao2870@gmail.com>
diff --git a/tools/crypto/ccp/dbc.py b/tools/crypto/ccp/dbc.py
index 2b91415b1940..cd56a63aa8ce 100644
--- a/tools/crypto/ccp/dbc.py
+++ b/tools/crypto/ccp/dbc.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/env python3
# SPDX-License-Identifier: GPL-2.0
import ctypes
diff --git a/tools/crypto/ccp/dbc_cli.py b/tools/crypto/ccp/dbc_cli.py
index bf52233fd038..bfe34f01e619 100755
--- a/tools/crypto/ccp/dbc_cli.py
+++ b/tools/crypto/ccp/dbc_cli.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/env python3
# SPDX-License-Identifier: GPL-2.0
import argparse
import binascii
diff --git a/tools/crypto/ccp/test_dbc.py b/tools/crypto/ccp/test_dbc.py
index bb0e671be96d..0ee3da6c6be7 100755
--- a/tools/crypto/ccp/test_dbc.py
+++ b/tools/crypto/ccp/test_dbc.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/env python3
# SPDX-License-Identifier: GPL-2.0
import unittest
import os
diff --git a/tools/perf/tests/shell/lib/perf_json_output_lint.py b/tools/perf/tests/shell/lib/perf_json_output_lint.py
index dafbde56cc76..dccafd507bb7 100644
--- a/tools/perf/tests/shell/lib/perf_json_output_lint.py
+++ b/tools/perf/tests/shell/lib/perf_json_output_lint.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python3
# SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
# Basic sanity check of perf JSON output as specified in the man page.
diff --git a/tools/testing/selftests/devices/probe/test_discoverable_devices.py b/tools/testing/selftests/devices/probe/test_discoverable_devices.py
index d7a2bb91c807..72a94bbfbc7b 100755
--- a/tools/testing/selftests/devices/probe/test_discoverable_devices.py
+++ b/tools/testing/selftests/devices/probe/test_discoverable_devices.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/env python3
# SPDX-License-Identifier: GPL-2.0
#
# Copyright (c) 2023 Collabora Ltd
diff --git a/tools/testing/selftests/rseq/rseq-slice-hist.py b/tools/testing/selftests/rseq/rseq-slice-hist.py
index b7933eeaefb9..2c43b2e2bf0d 100644
--- a/tools/testing/selftests/rseq/rseq-slice-hist.py
+++ b/tools/testing/selftests/rseq/rseq-slice-hist.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/env python3
#
# trace-cmd record -e hrtimer_start -e hrtimer_cancel -e hrtimer_expire_entry -- $cmd
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: Goffredo Baroncelli @ 2026-05-15 16:50 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Sterba, Andrew Morton, Catalin Marinas, Will Deacon,
Ard Biesheuvel, Huacai Chen, WANG Xuerui, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Herbert Xu, Dan Williams, Chris Mason, David Sterba,
Arnd Bergmann, Song Liu, Yu Kuai, Li Nan, linux-kernel,
linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv,
linux-s390, linux-crypto, linux-btrfs, linux-arch, linux-raid
In-Reply-To: <20260515043705.GA3855@lst.de>
On 15/05/2026 06.37, Christoph Hellwig wrote:
> On Thu, May 14, 2026 at 09:51:59PM +0200, Goffredo Baroncelli wrote:
>> I think that the David concern is : "what happens for an already
>> existing btrfs raid6 3 disks filesystem when the user upgrade the kernel ?"
>> (I am thinking when a new BG needs to be allocated)...
>
> Then it will cleanly fail to mount instead of constantly corrupting data
> and memory with every write, yes. Which clearly suggest that such
> file systems don't exist in the wild.
>
> But if btrfs wants to keep supporting this I'll just add a _unsafe
> version without the check in the core library.
>
I am not arguing about this part. My point is that the change shouldn't have impacted the
BTRFS interface versus the user (as patch 01/19 does), but instead the change should
have modify the interface raid code <-> btrfs (e.g. doing a memcpy....), or at least the
cover letter should warn that the raid6 code requires a number of disk >= 4, pointing
to BTRFS as "client doing wrong things".
At least, the message was received: don't relay to the raid6 code when the number of disk is
less than 4.
BR
GB
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: David Sterba @ 2026-05-15 14:51 UTC (permalink / raw)
To: H. Peter Anvin
Cc: kreijack, Goffredo Baroncelli, Christoph Hellwig, Andrew Morton,
Catalin Marinas, Will Deacon, Ard Biesheuvel, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <0507CCEF-0548-442F-8703-1D006B5E068B@zytor.com>
On Thu, May 14, 2026 at 12:57:53PM -0700, H. Peter Anvin wrote:
> On May 14, 2026 12:51:59 PM PDT, Goffredo Baroncelli <kreijack@libero.it> wrote:
> >On 13/05/2026 07.47, Christoph Hellwig wrote:
> >> On Tue, May 12, 2026 at 01:42:31PM +0200, David Sterba wrote:
> >
> >>
> >>> The degenerate modes of
> >>> raid0, 5, or 6 are explicit as a possible middle step when converting
> >>> profiles. We can use a fallback implementation for this case if the
> >>> accelerated implementations cannot do it.
> >>
> >> This is not about a degenerated mode. For a degenerated RAID 6, parity
> >> generation uses the RAID 5 XOR routines as the second parity will be
> >> missing. This is about generating two parities for a single data disk,
> >> which must be explicitly selected.
> >>
> >
> >I think that the David concern is : "what happens for an already
> >existing btrfs raid6 3 disks filesystem when the user upgrade the kernel ?"
> >(I am thinking when a new BG needs to be allocated)...
>
> That's what I'm saying – it should invoke the RAID-1 code under the cover (as with 3 disks, D = P = Q.)
Thanks, it was not clear to me what you meant. For the two edge cases
the code should do simple memcpy for both calculations of parity and
recovery.
^ permalink raw reply
* Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver
From: Krzysztof Kozlowski @ 2026-05-15 14:49 UTC (permalink / raw)
To: Linlin Zhang, Rob Herring, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: Herbert Xu, David S . Miller, devicetree, linux-crypto,
linux-arm-msm, linux-kernel, Neeraj Soni, Deepti Jaggi,
bjorn.andersson
In-Reply-To: <f0b90edc-6584-4b30-a2d1-e72139983fdb@kernel.org>
On 15/05/2026 16:48, Krzysztof Kozlowski wrote:
> On 15/05/2026 16:22, Linlin Zhang wrote:
>>
>> Hi Krzysztof,
>>
>> Thanks for the review.
>>
>> For the SCMI-based platforms (e.g. sa8255p), the ICE resources such as
>> clocks are not controlled directly by the ICE driver. Instead, they are
>> managed by remote firmware and exposed to Linux via power domains. As a
>> result, the ICE driver cannot use clk_prepare_enable() directly to
>> control the hardware clock.
>>
>> The intention of moving the clock handling into runtime PM callbacks is
>> to align the ICE driver with the power domain framework used on these
>> platforms. When the ICE device is attached to a power domain, invoking
>> pm_runtime_resume_and_get() will trigger the provider (remote firmware
>> via SCMI) to power up the device, which in turn enables the underlying
>> clock and other resources.
>>
>> This design follows the guidance where the runtime PM framework is
>> used as the common mechanism to abstract both:
>> - direct clock control on non-SCMI platforms, and
>> - firmware-controlled resources via power domains on SCMI platforms.
>>
>> In both cases, the runtime PM callbacks are responsible for performing
>> the actual resource enable/disable:
>> - for legacy platforms: clk_prepare_enable()/disable_unprepare()
>> - for SCMI platforms: power domain on/off handled by firmware
>>
>> So while it may look like an additional layer on legacy platforms, this
>> approach provides a unified mechanism without requiring separate driver
>> entry points or special handling in the upper layers (e.g. UFS driver).
>>
>> That said, I understand your concern that introducing runtime PM solely
>> for clock gating can be seen as unnecessary overhead on existing
>> platforms. I will revisit the implementation to ensure that:
>> - the runtime PM integration does not introduce regressions for legacy
>> platforms, and
>> - the design clearly justifies the common abstraction for both SCMI
>> and non-SCMI cases.
>>
>> In addition, I rewrite the commit message as the following to make the
>> intention more clear.
>>
>> On some platforms the ICE device is placed in a firmware-managed power
>> domain. In those cases the ICE core resources (including the clock) are
>> not directly controllable by Linux and are instead toggled by the power
>> domain provider (e.g. remote firmware via SCMI).
>>
>> Wire the ICE device into runtime PM so that a single pm_runtime
>> transition is used to bring the ICE device up/down. When the device is
>> attached to a PM domain, pm_runtime_resume_and_get()/pm_runtime_put_sync()
>> will invoke the PM domain callbacks and let the provider manage the
>> resources. On platforms without a PM domain the runtime PM callbacks
>> continue to perform the existing clock enable/disable locally.
>>
>> No functional change is intended for non-firmware-managed platforms; the
>> change provides a common control point that allows ICE to operate when
>> resources are owned by a PM domain provider.
>>
>
>
> Nothing here resolves the comments. Also, it's top posted. Honestly, I
> won't be talking through you with LLM, so consider patch NAKed.
Plus you completely ignored all the comments I posted in review. Great.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver
From: Krzysztof Kozlowski @ 2026-05-15 14:48 UTC (permalink / raw)
To: Linlin Zhang, Rob Herring, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: Herbert Xu, David S . Miller, devicetree, linux-crypto,
linux-arm-msm, linux-kernel, Neeraj Soni, Deepti Jaggi,
bjorn.andersson
In-Reply-To: <01578e6a-d10a-46df-bb32-fd45ecb365d7@oss.qualcomm.com>
On 15/05/2026 16:22, Linlin Zhang wrote:
>
> Hi Krzysztof,
>
> Thanks for the review.
>
> For the SCMI-based platforms (e.g. sa8255p), the ICE resources such as
> clocks are not controlled directly by the ICE driver. Instead, they are
> managed by remote firmware and exposed to Linux via power domains. As a
> result, the ICE driver cannot use clk_prepare_enable() directly to
> control the hardware clock.
>
> The intention of moving the clock handling into runtime PM callbacks is
> to align the ICE driver with the power domain framework used on these
> platforms. When the ICE device is attached to a power domain, invoking
> pm_runtime_resume_and_get() will trigger the provider (remote firmware
> via SCMI) to power up the device, which in turn enables the underlying
> clock and other resources.
>
> This design follows the guidance where the runtime PM framework is
> used as the common mechanism to abstract both:
> - direct clock control on non-SCMI platforms, and
> - firmware-controlled resources via power domains on SCMI platforms.
>
> In both cases, the runtime PM callbacks are responsible for performing
> the actual resource enable/disable:
> - for legacy platforms: clk_prepare_enable()/disable_unprepare()
> - for SCMI platforms: power domain on/off handled by firmware
>
> So while it may look like an additional layer on legacy platforms, this
> approach provides a unified mechanism without requiring separate driver
> entry points or special handling in the upper layers (e.g. UFS driver).
>
> That said, I understand your concern that introducing runtime PM solely
> for clock gating can be seen as unnecessary overhead on existing
> platforms. I will revisit the implementation to ensure that:
> - the runtime PM integration does not introduce regressions for legacy
> platforms, and
> - the design clearly justifies the common abstraction for both SCMI
> and non-SCMI cases.
>
> In addition, I rewrite the commit message as the following to make the
> intention more clear.
>
> On some platforms the ICE device is placed in a firmware-managed power
> domain. In those cases the ICE core resources (including the clock) are
> not directly controllable by Linux and are instead toggled by the power
> domain provider (e.g. remote firmware via SCMI).
>
> Wire the ICE device into runtime PM so that a single pm_runtime
> transition is used to bring the ICE device up/down. When the device is
> attached to a PM domain, pm_runtime_resume_and_get()/pm_runtime_put_sync()
> will invoke the PM domain callbacks and let the provider manage the
> resources. On platforms without a PM domain the runtime PM callbacks
> continue to perform the existing clock enable/disable locally.
>
> No functional change is intended for non-firmware-managed platforms; the
> change provides a common control point that allows ICE to operate when
> resources are owned by a PM domain provider.
>
Nothing here resolves the comments. Also, it's top posted. Honestly, I
won't be talking through you with LLM, so consider patch NAKed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver
From: Linlin Zhang @ 2026-05-15 14:22 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: Herbert Xu, David S . Miller, devicetree, linux-crypto,
linux-arm-msm, linux-kernel, Neeraj Soni, Deepti Jaggi,
bjorn.andersson
In-Reply-To: <b07a3634-a7a6-4f28-994b-fc900be26879@kernel.org>
Hi Krzysztof,
Thanks for the review.
For the SCMI-based platforms (e.g. sa8255p), the ICE resources such as
clocks are not controlled directly by the ICE driver. Instead, they are
managed by remote firmware and exposed to Linux via power domains. As a
result, the ICE driver cannot use clk_prepare_enable() directly to
control the hardware clock.
The intention of moving the clock handling into runtime PM callbacks is
to align the ICE driver with the power domain framework used on these
platforms. When the ICE device is attached to a power domain, invoking
pm_runtime_resume_and_get() will trigger the provider (remote firmware
via SCMI) to power up the device, which in turn enables the underlying
clock and other resources.
This design follows the guidance where the runtime PM framework is
used as the common mechanism to abstract both:
- direct clock control on non-SCMI platforms, and
- firmware-controlled resources via power domains on SCMI platforms.
In both cases, the runtime PM callbacks are responsible for performing
the actual resource enable/disable:
- for legacy platforms: clk_prepare_enable()/disable_unprepare()
- for SCMI platforms: power domain on/off handled by firmware
So while it may look like an additional layer on legacy platforms, this
approach provides a unified mechanism without requiring separate driver
entry points or special handling in the upper layers (e.g. UFS driver).
That said, I understand your concern that introducing runtime PM solely
for clock gating can be seen as unnecessary overhead on existing
platforms. I will revisit the implementation to ensure that:
- the runtime PM integration does not introduce regressions for legacy
platforms, and
- the design clearly justifies the common abstraction for both SCMI
and non-SCMI cases.
In addition, I rewrite the commit message as the following to make the
intention more clear.
On some platforms the ICE device is placed in a firmware-managed power
domain. In those cases the ICE core resources (including the clock) are
not directly controllable by Linux and are instead toggled by the power
domain provider (e.g. remote firmware via SCMI).
Wire the ICE device into runtime PM so that a single pm_runtime
transition is used to bring the ICE device up/down. When the device is
attached to a PM domain, pm_runtime_resume_and_get()/pm_runtime_put_sync()
will invoke the PM domain callbacks and let the provider manage the
resources. On platforms without a PM domain the runtime PM callbacks
continue to perform the existing clock enable/disable locally.
No functional change is intended for non-firmware-managed platforms; the
change provides a common control point that allows ICE to operate when
resources are owned by a PM domain provider.
Thanks again for the feedback. I would appreciate your further review
and comments.
Best regards,
Linlin
On 5/14/2026 10:06 PM, Krzysztof Kozlowski wrote:
> On 12/05/2026 05:37, Linlin Zhang wrote:
>> The QCOM ICE driver manages the ICE core clock through direct calls to
>> clk_prepare_enable() and clk_disable_unprepare(), which limits integration
>
> No, it does not limit any integration.
>
>> with platforms that rely on firmware-managed resources or platform-specific
>> power management mechanisms.
>
> Nope. It's perfectly correct way of managing clocks. Adding runtime PM
> ONLY to toggle clocks is absolute killer, pointless overhead without
> benefits.
>
>>
>> Replace direct clock management with runtime PM support by moving clock
>> enable and disable into runtime PM callbacks. Use
>> pm_runtime_resume_and_get() and pm_runtime_put_sync() in qcom_ice_resume()
>> and qcom_ice_suspend() to drive power state transitions, and enable runtime
>> PM in qcom_ice_probe().
>>
>> Reviewed-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
>> Reviewed-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
>> ---
>> drivers/soc/qcom/ice.c | 58 ++++++++++++++++++++++++++++++++++++++----
>> 1 file changed, 53 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
>> index b203bc685cad..6f9d679b530c 100644
>> --- a/drivers/soc/qcom/ice.c
>> +++ b/drivers/soc/qcom/ice.c
>> @@ -16,6 +16,7 @@
>> #include <linux/of.h>
>> #include <linux/of_platform.h>
>> #include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>>
>> #include <linux/firmware/qcom/qcom_scm.h>
>>
>> @@ -310,8 +311,8 @@ int qcom_ice_resume(struct qcom_ice *ice)
>> struct device *dev = ice->dev;
>> int err;
>>
>> - err = clk_prepare_enable(ice->core_clk);
>> - if (err) {
>> + err = pm_runtime_resume_and_get(dev);
>> + if (err < 0) {
>> dev_err(dev, "failed to enable core clock (%d)\n",
>> err);
>> return err;
>> @@ -323,7 +324,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
>>
>> int qcom_ice_suspend(struct qcom_ice *ice)
>> {
>> - clk_disable_unprepare(ice->core_clk);
>> + pm_runtime_put_sync(ice->dev);
>> ice->hwkm_init_complete = false;
>>
>> return 0;
>
>
> This is pretty pointless change. At least by quick glance. You changed
> nothing here for PM, except adding indirection layer and more locks.
> Clocks will be gated the same way, no energy savings. But on the other
> hand introducing runtime PM subsystem is huge bunch of code with its own
> locks, completely unnecessary here.
>
> This itself is poor choice and has NEGATIVE impact on all existing
> platforms without any benefit.
>
> I am surprised you went through SIX internal reviews, collected two
> internal review tags and no one suggested that using runtime PM ONLY to
> toggle clocks is pretty pointless and undesired.>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH 5.10-stable] lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()
From: Lukas Wunner @ 2026-05-15 14:16 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin
Cc: stable, linux-crypto, Eric Biggers, Ignat Korchagin,
Jarkko Sakkinen, Yiming Qian
commit 8c2f1288250a90a4b5cabed5d888d7e3aeed4035 upstream.
Yiming reports an integer underflow in mpi_read_raw_from_sgl() when
subtracting "lzeros" from the unsigned "nbytes".
For this to happen, the scatterlist "sgl" needs to occupy more bytes
than the "nbytes" parameter and the first "nbytes + 1" bytes of the
scatterlist must be zero. Under these conditions, the while loop
iterating over the scatterlist will count more zeroes than "nbytes",
subtract the number of zeroes from "nbytes" and cause the underflow.
When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally
introduced the bug, it couldn't be triggered because all callers of
mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to
"nbytes".
However since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto
interface without scatterlists"), the underflow can now actually be
triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a
larger "out_len" than "in_len" and filling the "in" buffer with zeroes,
crypto_akcipher_sync_prep() will create an all-zero scatterlist used for
both the "src" and "dst" member of struct akcipher_request and thereby
fulfil the conditions to trigger the bug:
sys_keyctl()
keyctl_pkey_e_d_s()
asymmetric_key_eds_op()
software_key_eds_op()
crypto_akcipher_sync_encrypt()
crypto_akcipher_sync_prep()
crypto_akcipher_encrypt()
rsa_enc()
mpi_read_raw_from_sgl()
To the user this will be visible as a DoS as the kernel spins forever,
causing soft lockup splats as a side effect.
Fix it.
Reported-by: Yiming Qian <yimingqian591@gmail.com> # off-list
Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v4.4+
Reviewed-by: Ignat Korchagin <ignat@linux.win>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/r/59eca92ff4f87e2081777f1423a0efaaadcfdb39.1776003111.git.lukas@wunner.de
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
lib/mpi/mpicoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index 7054311d7879..5d0a92fb3128 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -453,7 +453,7 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned int nbytes)
lzeros = 0;
len = 0;
while (nbytes > 0) {
- while (len && !*buff) {
+ while (len && !*buff && lzeros < nbytes) {
lzeros++;
len--;
buff++;
--
2.51.0
^ permalink raw reply related
* [PATCH 5.15-stable] lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()
From: Lukas Wunner @ 2026-05-15 14:12 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin
Cc: stable, linux-crypto, Eric Biggers, Ignat Korchagin,
Jarkko Sakkinen, Yiming Qian
commit 8c2f1288250a90a4b5cabed5d888d7e3aeed4035 upstream.
Yiming reports an integer underflow in mpi_read_raw_from_sgl() when
subtracting "lzeros" from the unsigned "nbytes".
For this to happen, the scatterlist "sgl" needs to occupy more bytes
than the "nbytes" parameter and the first "nbytes + 1" bytes of the
scatterlist must be zero. Under these conditions, the while loop
iterating over the scatterlist will count more zeroes than "nbytes",
subtract the number of zeroes from "nbytes" and cause the underflow.
When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally
introduced the bug, it couldn't be triggered because all callers of
mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to
"nbytes".
However since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto
interface without scatterlists"), the underflow can now actually be
triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a
larger "out_len" than "in_len" and filling the "in" buffer with zeroes,
crypto_akcipher_sync_prep() will create an all-zero scatterlist used for
both the "src" and "dst" member of struct akcipher_request and thereby
fulfil the conditions to trigger the bug:
sys_keyctl()
keyctl_pkey_e_d_s()
asymmetric_key_eds_op()
software_key_eds_op()
crypto_akcipher_sync_encrypt()
crypto_akcipher_sync_prep()
crypto_akcipher_encrypt()
rsa_enc()
mpi_read_raw_from_sgl()
To the user this will be visible as a DoS as the kernel spins forever,
causing soft lockup splats as a side effect.
Fix it.
Reported-by: Yiming Qian <yimingqian591@gmail.com> # off-list
Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v4.4+
Reviewed-by: Ignat Korchagin <ignat@linux.win>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/r/59eca92ff4f87e2081777f1423a0efaaadcfdb39.1776003111.git.lukas@wunner.de
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
lib/mpi/mpicoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index 3cb6bd148fa9..b6efe618e614 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -453,7 +453,7 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned int nbytes)
lzeros = 0;
len = 0;
while (nbytes > 0) {
- while (len && !*buff) {
+ while (len && !*buff && lzeros < nbytes) {
lzeros++;
len--;
buff++;
--
2.51.0
^ permalink raw reply related
* [PATCH 6.1-stable] lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()
From: Lukas Wunner @ 2026-05-15 14:04 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin
Cc: stable, linux-crypto, Eric Biggers, Ignat Korchagin,
Jarkko Sakkinen, Yiming Qian
commit 8c2f1288250a90a4b5cabed5d888d7e3aeed4035 upstream.
Yiming reports an integer underflow in mpi_read_raw_from_sgl() when
subtracting "lzeros" from the unsigned "nbytes".
For this to happen, the scatterlist "sgl" needs to occupy more bytes
than the "nbytes" parameter and the first "nbytes + 1" bytes of the
scatterlist must be zero. Under these conditions, the while loop
iterating over the scatterlist will count more zeroes than "nbytes",
subtract the number of zeroes from "nbytes" and cause the underflow.
When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally
introduced the bug, it couldn't be triggered because all callers of
mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to
"nbytes".
However since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto
interface without scatterlists"), the underflow can now actually be
triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a
larger "out_len" than "in_len" and filling the "in" buffer with zeroes,
crypto_akcipher_sync_prep() will create an all-zero scatterlist used for
both the "src" and "dst" member of struct akcipher_request and thereby
fulfil the conditions to trigger the bug:
sys_keyctl()
keyctl_pkey_e_d_s()
asymmetric_key_eds_op()
software_key_eds_op()
crypto_akcipher_sync_encrypt()
crypto_akcipher_sync_prep()
crypto_akcipher_encrypt()
rsa_enc()
mpi_read_raw_from_sgl()
To the user this will be visible as a DoS as the kernel spins forever,
causing soft lockup splats as a side effect.
Fix it.
Reported-by: Yiming Qian <yimingqian591@gmail.com> # off-list
Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v4.4+
Reviewed-by: Ignat Korchagin <ignat@linux.win>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/r/59eca92ff4f87e2081777f1423a0efaaadcfdb39.1776003111.git.lukas@wunner.de
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
lib/mpi/mpicoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index 3cb6bd148fa9..b6efe618e614 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -453,7 +453,7 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned int nbytes)
lzeros = 0;
len = 0;
while (nbytes > 0) {
- while (len && !*buff) {
+ while (len && !*buff && lzeros < nbytes) {
lzeros++;
len--;
buff++;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: crypto: qcom,ice: Add sa8255p support
From: Krzysztof Kozlowski @ 2026-05-15 13:26 UTC (permalink / raw)
To: Linlin Zhang
Cc: Rob Herring, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Herbert Xu, David S . Miller, devicetree, linux-crypto,
linux-arm-msm, linux-kernel
In-Reply-To: <56f5e73b-5f40-4bfb-9796-dadfcb4f9085@oss.qualcomm.com>
On 15/05/2026 15:23, Linlin Zhang wrote:
>
>
> On 5/14/2026 8:55 PM, Krzysztof Kozlowski wrote:
>> On Mon, May 11, 2026 at 08:37:48PM -0700, Linlin Zhang wrote:
>>> On sa8255p, resources such as PHY, clocks, regulators, and resets are
>>> managed by remote firmware via the SCMI power protocol. As a result, the
>>> ICE driver cannot directly access clocks and must instead use power-domains
>>> to request resource configuration.
>>
>> Then how can it be compatible with qcom,inline-crypto-engine?
>
> Thanks for the review.
>
> You are right that the SCMI-based implementation differs from the
> traditional inline crypto engine in terms of resource control. On
> sa8255p, clocks and other resources are managed by remote firmware
> via SCMI, so the driver does not directly control these resources
> and instead relies on power domains.
>
> Given this difference, the SCMI variant does not match the same
> programming model as the existing qcom,inline-crypto-engine
> implementation. Using it as a generic fallback is therefore not
> appropriate, as the generic compatible implies that the device can
> be handled equivalently by the same driver assumptions, which is
> not the case here.
Are you pasting here LLM responses? Two long paragraphs, written in over
formal English with no grammar errors and repeating standard AI slop
answer - "You are right".
Sending me LLM responses or LLM patches is unfortunately straight way to
get ignored.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: crypto: qcom,ice: Add sa8255p support
From: Linlin Zhang @ 2026-05-15 13:23 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Herbert Xu, David S . Miller, devicetree, linux-crypto,
linux-arm-msm, linux-kernel
In-Reply-To: <20260514-clever-apricot-goose-acc827@quoll>
On 5/14/2026 8:55 PM, Krzysztof Kozlowski wrote:
> On Mon, May 11, 2026 at 08:37:48PM -0700, Linlin Zhang wrote:
>> On sa8255p, resources such as PHY, clocks, regulators, and resets are
>> managed by remote firmware via the SCMI power protocol. As a result, the
>> ICE driver cannot directly access clocks and must instead use power-domains
>> to request resource configuration.
>
> Then how can it be compatible with qcom,inline-crypto-engine?
Thanks for the review.
You are right that the SCMI-based implementation differs from the
traditional inline crypto engine in terms of resource control. On
sa8255p, clocks and other resources are managed by remote firmware
via SCMI, so the driver does not directly control these resources
and instead relies on power domains.
Given this difference, the SCMI variant does not match the same
programming model as the existing qcom,inline-crypto-engine
implementation. Using it as a generic fallback is therefore not
appropriate, as the generic compatible implies that the device can
be handled equivalently by the same driver assumptions, which is
not the case here.
I will rework the bindings to:
- introduce a separate binding for the SCMI-based variant, and
- drop the generic fallback compatible string.
This should align better with other SCMI-based bindings and avoid
overloading the meaning of the generic compatible.
Thanks for pointing this out.
>
>>
>> Add the qcom,sa8255p-inline-crypto-engine compatible string and make clocks
>> optional for platforms that use power-domains instead.
>>
>> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
>> ---
>> .../crypto/qcom,inline-crypto-engine.yaml | 27 ++++++++++++++++++-
>> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> So this is v2? But previous was v6? Look:
>
> b4 diff '20260512033750.3393050-1-linlin.zhang@oss.qualcomm.com'
> Looking up https://lore.kernel.org/all/20260512033750.3393050-1-linlin.zhang@oss.qualcomm.com/
> Grabbing thread from lore.kernel.org/all/20260512033750.3393050-1-linlin.zhang@oss.qualcomm.com/t.mbox.gz
> Checking for older revisions
> Grabbing search results from lore.kernel.org
> ---
> Analyzing 8 messages in the thread
> Could not find lower series to compare against.
This patch was review internally, and the final version was v6 which is
approved for posting to upstream review. I'm sorry that I forgot update
the version to v1 when I posted this patch to https://lore.kernel.org/.
This is why you see the previous was v6.
I updated the patch to v2 (this is current patchset) with some changes.
Would you please help instruct me how to fix it? need I re-post the patch
serial from v1?
>
>
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> index 876bf90ed96e..4e7d9111d0eb 100644
>> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>
> This should go to its own binding file just like in all other
> SCMI-variant cases. And if you looked how these other files are done,
> you would see my complains already that generic fallback is most likely
> wrong.
>
> Otherwise explain me what the generic fallback means here and how is it
> supposed to work?
ACK. I'll separate the binding and remove the generic fallback.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2] crypto: krb5 - filter out async aead implementations at alloc
From: Michael Bommarito @ 2026-05-15 12:05 UTC (permalink / raw)
To: David Howells
Cc: Herbert Xu, David S. Miller, linux-crypto, Eric Biggers,
Marc Dionne, linux-afs, Ilya Dryomov, Xiubo Li, ceph-devel,
stable, linux-kernel
In-Reply-To: <2632015.1778845625@warthog.procyon.org.uk>
On Fri, May 15, 2026 at 7:47 AM David Howells <dhowells@redhat.com> wrote:
>
> Michael Bommarito <michael.bommarito@gmail.com> wrote:
>
> > - ci = crypto_alloc_aead(krb5->encrypt_name, 0, 0);
> > + ci = crypto_alloc_aead(krb5->encrypt_name, 0, CRYPTO_ALG_ASYNC);
>
> Apologies, but doesn't that do the opposite of what we want?
>
> Documentation/crypto/architecture.rst says:
>
> The mask flag restricts the type of cipher. The only allowed flag is
> CRYPTO_ALG_ASYNC to restrict the cipher lookup function to
> asynchronous ciphers. Usually, a caller provides a 0 for the mask
> flag.
>
> Don't we want only synchronous ciphers?
This suggestion originally came from Herbert, but when I checked it, I
missed that note and just looked at the code at crypto/api.c:71:
71 if ((q->cra_flags ^ type) & mask)
1 continue;
crypto_alloc_sync_aead does the same thing at L212 in aead.c.
So the bit mask should filter the way we want, despite the
documentation's implication. Perhaps we should separately update that
line in the docs to be more clear about filter and how to properly use
it.
Thanks,
Mike
^ permalink raw reply
* [PATCH 3/3] crypto: hisilicon/hpre - implement full backlog support for hpre driver
From: ZongYu Wu @ 2026-05-15 11:46 UTC (permalink / raw)
To: herbert, davem
Cc: linux-kernel, linux-crypto, fanghao11, liulongfang, qianweili,
wangzhou1
In-Reply-To: <20260515114601.2492524-1-wuzongyu1@huawei.com>
From: lizhi <lizhi206@huawei.com>
When the hardware queue returns -EBUSY, requests are queued instead of
being failed immediately. The driver retries queued requests from the
completion path after earlier requests have finished.
This reduces request failures caused by temporary hardware congestion and
improves throughput and stability under high load.
Signed-off-by: lizhi <lizhi206@huawei.com>
Signed-off-by: Zongyu Wu <wuzongyu1@huawei.com>
---
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 223 +++++++++++++++-----
1 file changed, 166 insertions(+), 57 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 09077abbf6ad..5d5c4d5a9fbc 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -30,6 +30,7 @@ struct hpre_ctx;
#define HPRE_DH_G_FLAG 0x02
#define HPRE_TRY_SEND_TIMES 100
#define HPRE_INVLD_REQ_ID (-1)
+#define HPRE_ALG_TYPE_MASK 0x1F
#define HPRE_SQE_ALG_BITS 5
#define HPRE_SQE_DONE_SHIFT 30
@@ -39,6 +40,7 @@ struct hpre_ctx;
#define HPRE_DFX_US_TO_NS 1000
#define HPRE_ENABLE_HPCORE_SHIFT 7
+#define HPRE_ECDH_CLR_DATA_SHIFT 2
/* due to nist p521 */
#define HPRE_ECC_MAX_KSZ 66
@@ -138,6 +140,8 @@ struct hpre_asym_request {
int err;
hpre_cb cb;
struct timespec64 req_time;
+ struct crypto_async_request *base;
+ struct list_head list;
};
static inline unsigned int hpre_align_sz(void)
@@ -241,8 +245,8 @@ static void hpre_hw_data_clr_all(struct hpre_ctx *ctx,
struct scatterlist *dst,
struct scatterlist *src)
{
- struct device *dev = ctx->dev;
struct hpre_sqe *sqe = &req->req;
+ struct device *dev = ctx->dev;
dma_addr_t tmp;
tmp = le64_to_cpu(sqe->in);
@@ -270,6 +274,34 @@ static void hpre_hw_data_clr_all(struct hpre_ctx *ctx,
}
}
+static void hpre_ecdh_hw_data_clr_all(struct hpre_ctx *ctx,
+ struct hpre_asym_request *req,
+ struct scatterlist *dst,
+ struct scatterlist *src)
+{
+ struct hpre_sqe *sqe = &req->req;
+ struct device *dev = ctx->dev;
+ dma_addr_t dma;
+
+ dma = le64_to_cpu(sqe->in);
+ if (unlikely(dma_mapping_error(dev, dma)))
+ return;
+
+ /* req->src may contain garbage value, check both src and req->src before freeing */
+ if (src && req->src)
+ dma_free_coherent(dev, ctx->key_sz << HPRE_ECDH_CLR_DATA_SHIFT,
+ req->src, dma);
+
+ dma = le64_to_cpu(sqe->out);
+ if (unlikely(dma_mapping_error(dev, dma)))
+ return;
+
+ if (req->dst)
+ dma_free_coherent(dev, ctx->key_sz << 1, req->dst, dma);
+ if (dst)
+ dma_unmap_single(dev, dma, ctx->key_sz << 1, DMA_FROM_DEVICE);
+}
+
static int hpre_alg_res_post_hf(struct hpre_ctx *ctx, struct hpre_sqe *sqe,
void **kreq)
{
@@ -323,6 +355,94 @@ static bool hpre_is_bd_timeout(struct hpre_asym_request *req,
return true;
}
+static int hpre_send(struct hpre_ctx *ctx, struct hpre_sqe *msg)
+{
+ struct hpre_dfx *dfx = ctx->hpre->debug.dfx;
+ int cnt = 0;
+ int ret;
+
+ do {
+ ret = hisi_qp_send(ctx->qp, msg);
+ if (ret != -EBUSY)
+ break;
+ atomic64_inc(&dfx[HPRE_SEND_BUSY_CNT].value);
+ } while (cnt++ < HPRE_TRY_SEND_TIMES);
+
+ if (likely(!ret)) {
+ atomic64_inc(&dfx[HPRE_SEND_CNT].value);
+ return ret;
+ }
+
+ if (ret != -EBUSY)
+ atomic64_inc(&dfx[HPRE_SEND_FAIL_CNT].value);
+
+ return ret;
+}
+
+static int hpre_send_backlog(struct hpre_ctx *ctx, struct hpre_sqe *msg)
+{
+ struct hpre_dfx *dfx = ctx->hpre->debug.dfx;
+ int ret;
+
+ ret = hisi_qp_send(ctx->qp, msg);
+ if (likely(!ret))
+ atomic64_inc(&dfx[HPRE_SEND_CNT].value);
+ else if (unlikely(ret != -EBUSY))
+ atomic64_inc(&dfx[HPRE_SEND_FAIL_CNT].value);
+ else
+ atomic64_inc(&dfx[HPRE_SEND_BUSY_CNT].value);
+
+ return ret;
+}
+
+static void hpre_alg_hw_data_clr_all(struct hpre_ctx *ctx, struct hpre_asym_request *h_req)
+{
+ switch (le32_to_cpu(h_req->req.dw0) & HPRE_ALG_TYPE_MASK) {
+ case HPRE_ALG_DH_G2:
+ case HPRE_ALG_DH:
+ hpre_hw_data_clr_all(ctx, h_req, h_req->areq.dh->dst, h_req->areq.dh->src);
+ break;
+ case HPRE_ALG_NC_NCRT:
+ case HPRE_ALG_NC_CRT:
+ hpre_hw_data_clr_all(ctx, h_req, h_req->areq.rsa->dst, h_req->areq.rsa->src);
+ break;
+ case HPRE_ALG_ECC_MUL:
+ hpre_ecdh_hw_data_clr_all(ctx, h_req, h_req->areq.ecdh->dst, h_req->areq.ecdh->src);
+ break;
+ default:
+ break;
+ }
+}
+
+static void hpre_alg_send_backlog(struct hisi_qp *qp)
+{
+ struct hpre_asym_request *req, *tmp;
+ int ret;
+
+ spin_lock_bh(&qp->backlog.lock);
+ list_for_each_entry_safe(req, tmp, &qp->backlog.list, list) {
+ ret = hpre_send_backlog(req->ctx, &req->req);
+ switch (ret) {
+ case 0:
+ list_del(&req->list);
+ crypto_request_complete(req->base, -EINPROGRESS);
+ break;
+ case -EBUSY:
+ /* Device is busy and stop send any request. */
+ goto unlock;
+ default:
+ /* Current no fallback for any send error. */
+ list_del(&req->list);
+ hpre_alg_hw_data_clr_all(req->ctx, req);
+ crypto_request_complete(req->base, -EIO);
+ break;
+ }
+ }
+
+unlock:
+ spin_unlock_bh(&qp->backlog.lock);
+}
+
static void hpre_dh_cb(struct hpre_ctx *ctx, void *resp)
{
struct hpre_dfx *dfx = ctx->hpre->debug.dfx;
@@ -377,6 +497,7 @@ static void hpre_alg_cb(struct hisi_qp *qp, void *resp)
}
h_req->cb(h_req->ctx, resp);
+ hpre_alg_send_backlog(qp);
}
static int hpre_ctx_init(struct hpre_ctx *ctx, u8 type)
@@ -450,25 +571,39 @@ static int hpre_msg_request_set(struct hpre_ctx *ctx, void *req, bool is_rsa)
return 0;
}
-static int hpre_send(struct hpre_ctx *ctx, struct hpre_sqe *msg)
+static int hpre_alg_try_enqueue(struct hpre_asym_request *hpre_req)
{
- struct hpre_dfx *dfx = ctx->hpre->debug.dfx;
- int ctr = 0;
+ struct hisi_qp *qp = hpre_req->ctx->qp;
+
+ /* Check if any request is already backlogged */
+ if (!list_empty(&qp->backlog.list))
+ return -EBUSY;
+
+ /* Try to enqueue to HW ring */
+ return hpre_send_backlog(hpre_req->ctx, &hpre_req->req);
+}
+
+static int hpre_alg_send_message(struct hpre_asym_request *hpre_req)
+{
+ struct hisi_qp *qp = hpre_req->ctx->qp;
int ret;
- do {
- atomic64_inc(&dfx[HPRE_SEND_CNT].value);
- ret = hisi_qp_send(ctx->qp, msg);
- if (ret != -EBUSY)
- break;
- atomic64_inc(&dfx[HPRE_SEND_BUSY_CNT].value);
- } while (ctr++ < HPRE_TRY_SEND_TIMES);
+ if (!(hpre_req->base->flags & CRYPTO_TFM_REQ_MAY_BACKLOG)) {
+ ret = hpre_send(hpre_req->ctx, &hpre_req->req);
+ if (ret == -EBUSY)
+ return -ENOSPC;
+ } else {
+ ret = hpre_alg_try_enqueue(hpre_req);
+ if (ret == -EBUSY) {
+ spin_lock_bh(&qp->backlog.lock);
+ list_add_tail(&hpre_req->list, &qp->backlog.list);
+ spin_unlock_bh(&qp->backlog.lock);
+ return -EBUSY;
+ }
+ }
if (likely(!ret))
- return ret;
-
- if (ret != -EBUSY)
- atomic64_inc(&dfx[HPRE_SEND_FAIL_CNT].value);
+ return -EINPROGRESS;
return ret;
}
@@ -482,6 +617,7 @@ static int hpre_dh_compute_value(struct kpp_request *req)
struct hpre_sqe *msg = &hpre_req->req;
int ret;
+ hpre_req->base = &req->base;
ret = hpre_msg_request_set(ctx, req, false);
if (unlikely(ret))
return ret;
@@ -503,14 +639,12 @@ static int hpre_dh_compute_value(struct kpp_request *req)
else
msg->dw0 = cpu_to_le32(le32_to_cpu(msg->dw0) | HPRE_ALG_DH);
- /* success */
- ret = hpre_send(ctx, msg);
- if (likely(!ret))
- return -EINPROGRESS;
+ ret = hpre_alg_send_message(hpre_req);
+ if (likely(ret == -EINPROGRESS || ret == -EBUSY))
+ return ret;
clear_all:
hpre_hw_data_clr_all(ctx, hpre_req, req->dst, req->src);
-
return ret;
}
@@ -755,6 +889,7 @@ static int hpre_rsa_enc(struct akcipher_request *req)
struct hpre_sqe *msg = &hpre_req->req;
int ret;
+ hpre_req->base = &req->base;
/* For unsupported key size and unavailable devices, use soft tfm instead */
if (ctx->fallback) {
akcipher_request_set_tfm(req, ctx->rsa.soft_tfm);
@@ -781,10 +916,9 @@ static int hpre_rsa_enc(struct akcipher_request *req)
if (unlikely(ret))
goto clear_all;
- /* success */
- ret = hpre_send(ctx, msg);
- if (likely(!ret))
- return -EINPROGRESS;
+ ret = hpre_alg_send_message(hpre_req);
+ if (likely(ret == -EINPROGRESS || ret == -EBUSY))
+ return ret;
clear_all:
hpre_hw_data_clr_all(ctx, hpre_req, req->dst, req->src);
@@ -801,6 +935,7 @@ static int hpre_rsa_dec(struct akcipher_request *req)
struct hpre_sqe *msg = &hpre_req->req;
int ret;
+ hpre_req->base = &req->base;
/* For unsupported key size and unavailable devices, use soft tfm instead */
if (ctx->fallback) {
akcipher_request_set_tfm(req, ctx->rsa.soft_tfm);
@@ -834,10 +969,9 @@ static int hpre_rsa_dec(struct akcipher_request *req)
if (unlikely(ret))
goto clear_all;
- /* success */
- ret = hpre_send(ctx, msg);
- if (likely(!ret))
- return -EINPROGRESS;
+ ret = hpre_alg_send_message(hpre_req);
+ if (likely(ret == -EINPROGRESS || ret == -EBUSY))
+ return ret;
clear_all:
hpre_hw_data_clr_all(ctx, hpre_req, req->dst, req->src);
@@ -1387,32 +1521,6 @@ static int hpre_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
return 0;
}
-static void hpre_ecdh_hw_data_clr_all(struct hpre_ctx *ctx,
- struct hpre_asym_request *req,
- struct scatterlist *dst,
- struct scatterlist *src)
-{
- struct device *dev = ctx->dev;
- struct hpre_sqe *sqe = &req->req;
- dma_addr_t dma;
-
- dma = le64_to_cpu(sqe->in);
- if (unlikely(dma_mapping_error(dev, dma)))
- return;
-
- if (src && req->src)
- dma_free_coherent(dev, ctx->key_sz << 2, req->src, dma);
-
- dma = le64_to_cpu(sqe->out);
- if (unlikely(dma_mapping_error(dev, dma)))
- return;
-
- if (req->dst)
- dma_free_coherent(dev, ctx->key_sz << 1, req->dst, dma);
- if (dst)
- dma_unmap_single(dev, dma, ctx->key_sz << 1, DMA_FROM_DEVICE);
-}
-
static void hpre_ecdh_cb(struct hpre_ctx *ctx, void *resp)
{
unsigned int curve_sz = hpre_ecdh_get_curvesz(ctx->curve_id);
@@ -1538,6 +1646,7 @@ static int hpre_ecdh_compute_value(struct kpp_request *req)
struct hpre_sqe *msg = &hpre_req->req;
int ret;
+ hpre_req->base = &req->base;
ret = hpre_ecdh_msg_request_set(ctx, req);
if (unlikely(ret)) {
dev_err(dev, "failed to set ecdh request, ret = %d!\n", ret);
@@ -1563,9 +1672,9 @@ static int hpre_ecdh_compute_value(struct kpp_request *req)
msg->dw0 = cpu_to_le32(le32_to_cpu(msg->dw0) | HPRE_ALG_ECC_MUL);
msg->resv1 = ctx->enable_hpcore << HPRE_ENABLE_HPCORE_SHIFT;
- ret = hpre_send(ctx, msg);
- if (likely(!ret))
- return -EINPROGRESS;
+ ret = hpre_alg_send_message(hpre_req);
+ if (likely(ret == -EINPROGRESS || ret == -EBUSY))
+ return ret;
clear_all:
hpre_ecdh_hw_data_clr_all(ctx, hpre_req, req->dst, req->src);
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] crypto: hisilicon/sec2 - fix UAF in sec_alg_send_backlog
From: ZongYu Wu @ 2026-05-15 11:46 UTC (permalink / raw)
To: herbert, davem
Cc: linux-kernel, linux-crypto, fanghao11, liulongfang, qianweili,
wangzhou1
In-Reply-To: <20260515114601.2492524-1-wuzongyu1@huawei.com>
From: Wenkai Lin <linwenkai6@hisilicon.com>
After crypto_request_complete() is invoked, the crypto core may
immediately free the request structure and its associated tfm context.
Consequently, the sec_ctx and qp_ctx are also released.
However, sec_alg_send_backlog() can still attempt to access these
structures when processing queued requests, resulting in a
use-after-free (UAF) bug.
Fix this by accessing the backlog list through the long-term qp memory
and using the ctx memory only when the backlog list is not empty.
Fixes: f0ae287c5045 ("crypto: hisilicon/sec2 - implement full backlog mode for sec")
Signed-off-by: Wenkai Lin <linwenkai6@hisilicon.com>
Signed-off-by: Zongyu Wu <wuzongyu1@huawei.com>
---
drivers/crypto/hisilicon/sec2/sec_crypto.c | 23 +++++++++++-----------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c b/drivers/crypto/hisilicon/sec2/sec_crypto.c
index 2471a4dd0b50..7f2c81170431 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c
@@ -234,13 +234,15 @@ static int qp_send_message(struct sec_req *req)
return -EINPROGRESS;
}
-static void sec_alg_send_backlog_soft(struct sec_ctx *ctx, struct sec_qp_ctx *qp_ctx)
+static void sec_alg_send_backlog_soft(struct hisi_qp *qp)
{
struct sec_req *req, *tmp;
+ struct sec_ctx *ctx;
int ret;
- list_for_each_entry_safe(req, tmp, &qp_ctx->qp->backlog.list, list) {
+ list_for_each_entry_safe(req, tmp, &qp->backlog.list, list) {
list_del(&req->list);
+ ctx = req->qp_ctx->ctx;
ctx->req_op->buf_unmap(ctx, req);
if (req->req_id >= 0)
sec_free_req_id(req);
@@ -258,9 +260,8 @@ static void sec_alg_send_backlog_soft(struct sec_ctx *ctx, struct sec_qp_ctx *qp
}
}
-static void sec_alg_send_backlog(struct sec_ctx *ctx, struct sec_qp_ctx *qp_ctx)
+static void sec_alg_send_backlog(struct hisi_qp *qp)
{
- struct hisi_qp *qp = qp_ctx->qp;
struct sec_req *req, *tmp;
int ret;
@@ -277,7 +278,7 @@ static void sec_alg_send_backlog(struct sec_ctx *ctx, struct sec_qp_ctx *qp_ctx)
goto unlock;
default:
/* Release memory resources and send all requests through software. */
- sec_alg_send_backlog_soft(ctx, qp_ctx);
+ sec_alg_send_backlog_soft(qp);
goto unlock;
}
}
@@ -306,6 +307,7 @@ static void sec_req_cb(struct hisi_qp *qp, void *resp)
ctx->req_op->buf_unmap(ctx, req);
ctx->req_op->callback(ctx, req, err);
+ sec_alg_send_backlog(qp);
}
static void sec_req_cb3(struct hisi_qp *qp, void *resp)
@@ -331,6 +333,7 @@ static void sec_req_cb3(struct hisi_qp *qp, void *resp)
ctx->req_op->buf_unmap(ctx, req);
ctx->req_op->callback(ctx, req, err);
+ sec_alg_send_backlog(qp);
}
static int sec_alg_send_message_retry(struct sec_req *req)
@@ -1673,8 +1676,6 @@ static void sec_update_iv(struct sec_req *req, enum sec_alg_type alg_type)
static void sec_skcipher_callback(struct sec_ctx *ctx, struct sec_req *req,
int err)
{
- struct sec_qp_ctx *qp_ctx = req->qp_ctx;
-
if (req->req_id >= 0)
sec_free_req_id(req);
@@ -1684,7 +1685,6 @@ static void sec_skcipher_callback(struct sec_ctx *ctx, struct sec_req *req,
sec_update_iv(req, SEC_SKCIPHER);
crypto_request_complete(req->base, err);
- sec_alg_send_backlog(ctx, qp_ctx);
}
static void set_aead_auth_iv(struct sec_ctx *ctx, struct sec_req *req)
@@ -1923,7 +1923,7 @@ static void sec_aead_callback(struct sec_ctx *c, struct sec_req *req, int err)
struct aead_request *a_req = req->aead_req.aead_req;
struct crypto_aead *tfm = crypto_aead_reqtfm(a_req);
size_t authsize = crypto_aead_authsize(tfm);
- struct sec_qp_ctx *qp_ctx = req->qp_ctx;
+ int error = err;
size_t sz;
if (!err && req->c_req.encrypt) {
@@ -1934,15 +1934,14 @@ static void sec_aead_callback(struct sec_ctx *c, struct sec_req *req, int err)
authsize, a_req->cryptlen + a_req->assoclen);
if (unlikely(sz != authsize)) {
dev_err(c->dev, "copy out mac err!\n");
- err = -EINVAL;
+ error = -EINVAL;
}
}
if (req->req_id >= 0)
sec_free_req_id(req);
- crypto_request_complete(req->base, err);
- sec_alg_send_backlog(c, qp_ctx);
+ crypto_request_complete(req->base, error);
}
static void sec_request_uninit(struct sec_req *req)
--
2.43.0
^ permalink raw reply related
* [PATCH] crypto: hisilicon/zip - add backlog support for zip
From: ZongYu Wu @ 2026-05-15 11:45 UTC (permalink / raw)
To: herbert, davem
Cc: linux-kernel, linux-crypto, fanghao11, liulongfang, qianweili,
wangzhou1
In-Reply-To: <20260515114601.2492524-1-wuzongyu1@huawei.com>
From: Chenghai Huang <huangchenghai2@huawei.com>
When the hardware queue is busy, requests are now queued instead of
being failed immediately. Queued requests are retried when earlier
requests complete, which prevents transient failures under heavy load.
The backlog path also provides a fallback mechanism while the hardware
is temporarily unavailable, such as during device reset.
Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
Signed-off-by: Zongyu Wu <wuzongyu1@huawei.com>
---
drivers/crypto/hisilicon/zip/zip_crypto.c | 284 ++++++++++++++--------
1 file changed, 180 insertions(+), 104 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c b/drivers/crypto/hisilicon/zip/zip_crypto.c
index 70adde049b53..ff287251218e 100644
--- a/drivers/crypto/hisilicon/zip/zip_crypto.c
+++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
@@ -28,6 +28,7 @@
#define HZIP_ALG_DEFLATE GENMASK(5, 4)
#define HZIP_ALG_LZ4 BIT(8)
+#define HZIP_INVAL_REQ_ID ((u16)0xFFFF)
static DEFINE_MUTEX(zip_algs_lock);
static unsigned int zip_available_devs;
@@ -55,11 +56,11 @@ struct hisi_zip_req {
dma_addr_t dma_src;
dma_addr_t dma_dst;
struct hisi_zip_qp_ctx *qp_ctx;
+ struct list_head list;
u16 req_id;
};
struct hisi_zip_req_q {
- struct hisi_zip_req *q;
unsigned long *req_bitmap;
spinlock_t req_lock;
u16 size;
@@ -135,42 +136,42 @@ static int hisi_zip_fallback_do_work(struct acomp_req *acomp_req, bool is_decomp
return ret;
}
-static struct hisi_zip_req *hisi_zip_create_req(struct hisi_zip_qp_ctx *qp_ctx,
- struct acomp_req *req)
+static int hisi_zip_create_req(struct hisi_zip_req *req)
{
+ struct hisi_zip_qp_ctx *qp_ctx = req->qp_ctx;
struct hisi_zip_req_q *req_q = &qp_ctx->req_q;
- struct hisi_zip_req *q = req_q->q;
- struct hisi_zip_req *req_cache;
int req_id;
+ /* Check whether any request is being queued */
+ if (!list_empty(&qp_ctx->qp->backlog.list))
+ return -EBUSY;
+
spin_lock(&req_q->req_lock);
req_id = find_first_zero_bit(req_q->req_bitmap, req_q->size);
if (req_id >= req_q->size) {
spin_unlock(&req_q->req_lock);
dev_dbg(&qp_ctx->qp->qm->pdev->dev, "req cache is full!\n");
- return ERR_PTR(-EAGAIN);
+ return -EBUSY;
}
set_bit(req_id, req_q->req_bitmap);
spin_unlock(&req_q->req_lock);
- req_cache = q + req_id;
- req_cache->req_id = req_id;
- req_cache->req = req;
- req_cache->qp_ctx = qp_ctx;
+ req->req_id = req_id;
- return req_cache;
+ return 0;
}
-static void hisi_zip_remove_req(struct hisi_zip_qp_ctx *qp_ctx,
- struct hisi_zip_req *req)
+static void hisi_zip_remove_req(struct hisi_zip_req *req)
{
- struct hisi_zip_req_q *req_q = &qp_ctx->req_q;
+ struct hisi_zip_req_q *req_q = &req->qp_ctx->req_q;
spin_lock(&req_q->req_lock);
clear_bit(req->req_id, req_q->req_bitmap);
spin_unlock(&req_q->req_lock);
+
+ req->req_id = HZIP_INVAL_REQ_ID;
}
static void hisi_zip_fill_addr(struct hisi_zip_sqe *sqe, struct hisi_zip_req *req)
@@ -247,19 +248,21 @@ static void hisi_zip_fill_sqe(struct hisi_zip_ctx *ctx, struct hisi_zip_sqe *sqe
ops->fill_sqe_type(sqe, ops->sqe_type);
}
-static int hisi_zip_do_work(struct hisi_zip_qp_ctx *qp_ctx,
- struct hisi_zip_req *req)
+static void hisi_zip_enqueue_backlog(struct hisi_zip_req *req)
+{
+ struct hisi_qp *qp = req->qp_ctx->qp;
+
+ spin_lock_bh(&qp->backlog.lock);
+ list_add_tail(&req->list, &qp->backlog.list);
+ spin_unlock_bh(&qp->backlog.lock);
+}
+
+static int hisi_zip_map_req_buffers(struct hisi_zip_req *req)
{
+ struct hisi_zip_qp_ctx *qp_ctx = req->qp_ctx;
struct hisi_acc_sgl_pool *pool = qp_ctx->sgl_pool;
- struct hisi_zip_dfx *dfx = &qp_ctx->zip_dev->dfx;
+ struct device *dev = &qp_ctx->qp->qm->pdev->dev;
struct acomp_req *a_req = req->req;
- struct hisi_qp *qp = qp_ctx->qp;
- struct device *dev = &qp->qm->pdev->dev;
- struct hisi_zip_sqe zip_sqe;
- int ret;
-
- if (unlikely(!a_req->src || !a_req->slen || !a_req->dst || !a_req->dlen))
- return -EINVAL;
req->hw_src = hisi_acc_sg_buf_map_to_hw_sgl(dev, a_req->src, pool,
req->req_id << 1, &req->dma_src,
@@ -274,33 +277,110 @@ static int hisi_zip_do_work(struct hisi_zip_qp_ctx *qp_ctx,
(req->req_id << 1) + 1,
&req->dma_dst, DMA_FROM_DEVICE);
if (IS_ERR(req->hw_dst)) {
- ret = PTR_ERR(req->hw_dst);
- dev_err(dev, "failed to map the dst buffer to hw sgl (%d)!\n",
- ret);
- goto err_unmap_input;
+ dev_err(dev, "failed to map the dst buffer to hw sgl (%ld)!\n",
+ PTR_ERR(req->hw_dst));
+ hisi_acc_sg_buf_unmap(dev, a_req->src, req->hw_src, DMA_TO_DEVICE);
+ return PTR_ERR(req->hw_dst);
}
+ return 0;
+}
+
+static void hisi_zip_unmap_req_buffers(struct hisi_zip_req *req)
+{
+ struct device *dev = &req->qp_ctx->qp->qm->pdev->dev;
+ struct acomp_req *a_req = req->req;
+
+ hisi_acc_sg_buf_unmap(dev, a_req->dst, req->hw_dst, DMA_FROM_DEVICE);
+ hisi_acc_sg_buf_unmap(dev, a_req->src, req->hw_src, DMA_TO_DEVICE);
+}
+
+static int hisi_zip_do_work(struct hisi_zip_req *req)
+{
+ struct hisi_zip_qp_ctx *qp_ctx = req->qp_ctx;
+ struct hisi_zip_dfx *dfx = &qp_ctx->zip_dev->dfx;
+ struct hisi_qp *qp = qp_ctx->qp;
+ struct hisi_zip_sqe zip_sqe;
+ int ret;
+
hisi_zip_fill_sqe(qp_ctx->ctx, &zip_sqe, qp_ctx->req_type, req);
/* send command to start a task */
- atomic64_inc(&dfx->send_cnt);
ret = hisi_qp_send(qp, &zip_sqe);
- if (unlikely(ret < 0)) {
- atomic64_inc(&dfx->send_busy_cnt);
- ret = -EAGAIN;
- dev_dbg_ratelimited(dev, "failed to send request!\n");
- goto err_unmap_output;
+ if (likely(!ret)) {
+ atomic64_inc(&dfx->send_cnt);
+ return -EINPROGRESS;
}
- return -EINPROGRESS;
+ if (ret == -EBUSY)
+ atomic64_inc(&dfx->send_busy_cnt);
-err_unmap_output:
- hisi_acc_sg_buf_unmap(dev, a_req->dst, req->hw_dst, DMA_FROM_DEVICE);
-err_unmap_input:
- hisi_acc_sg_buf_unmap(dev, a_req->src, req->hw_src, DMA_TO_DEVICE);
return ret;
}
+static void hisi_zip_send_backlog_soft(struct hisi_zip_qp_ctx *qp_ctx)
+{
+ bool is_decomp = qp_ctx->qp->alg_type;
+ struct hisi_zip_req *req, *tmp;
+ int ret;
+
+ list_for_each_entry_safe(req, tmp, &qp_ctx->qp->backlog.list, list) {
+ list_del(&req->list);
+
+ if (req->req_id != HZIP_INVAL_REQ_ID) {
+ hisi_zip_unmap_req_buffers(req);
+ hisi_zip_remove_req(req);
+ }
+
+ ret = hisi_zip_fallback_do_work(req->req, is_decomp);
+
+ /* Wake up the busy thread first, then return the errno. */
+ if (req->req->base.complete) {
+ acomp_request_complete(req->req, -EINPROGRESS);
+ acomp_request_complete(req->req, ret);
+ }
+ }
+}
+
+static void hisi_zip_send_backlog(struct hisi_qp *qp)
+{
+ struct hisi_zip_req *req, *tmp;
+ int ret;
+
+ spin_lock_bh(&qp->backlog.lock);
+ list_for_each_entry_safe(req, tmp, &qp->backlog.list, list) {
+ if (req->req_id == HZIP_INVAL_REQ_ID) {
+ ret = hisi_zip_create_req(req);
+ if (ret)
+ continue;
+
+ ret = hisi_zip_map_req_buffers(req);
+ if (unlikely(ret)) {
+ hisi_zip_remove_req(req);
+ hisi_zip_send_backlog_soft(req->qp_ctx);
+ goto unlock;
+ }
+ }
+
+ ret = hisi_zip_do_work(req);
+ switch (ret) {
+ case -EINPROGRESS:
+ list_del(&req->list);
+ if (req->req->base.complete)
+ acomp_request_complete(req->req, -EINPROGRESS);
+ break;
+ case -EBUSY:
+ goto unlock;
+ default:
+ hisi_zip_send_backlog_soft(req->qp_ctx);
+ goto unlock;
+ }
+ }
+
+unlock:
+ spin_unlock_bh(&qp->backlog.lock);
+}
+
static u32 hisi_zip_get_status(struct hisi_zip_sqe *sqe)
{
return sqe->dw3 & HZIP_BD_STATUS_M;
@@ -333,73 +413,89 @@ static void hisi_zip_acomp_cb(struct hisi_qp *qp, void *data)
err = -EIO;
}
- hisi_acc_sg_buf_unmap(dev, acomp_req->dst, req->hw_dst, DMA_FROM_DEVICE);
- hisi_acc_sg_buf_unmap(dev, acomp_req->src, req->hw_src, DMA_TO_DEVICE);
+ hisi_zip_unmap_req_buffers(req);
acomp_req->dlen = ops->get_dstlen(sqe);
+ hisi_zip_remove_req(req);
if (acomp_req->base.complete)
acomp_request_complete(acomp_req, err);
- hisi_zip_remove_req(qp_ctx, req);
+ hisi_zip_send_backlog(qp);
}
-static int hisi_zip_acompress(struct acomp_req *acomp_req)
+static int hisi_zip_do_comp(struct hisi_zip_req *req)
{
+ struct acomp_req *acomp_req = req->req;
struct hisi_zip_ctx *ctx = crypto_tfm_ctx(acomp_req->base.tfm);
- struct hisi_zip_qp_ctx *qp_ctx = &ctx->qp_ctx[HZIP_QPC_COMP];
- struct hisi_zip_req *req;
- struct device *dev;
+ struct hisi_qp *qp = req->qp_ctx->qp;
int ret;
- if (ctx->fallback)
- return hisi_zip_fallback_do_work(acomp_req, 0);
-
- dev = &qp_ctx->qp->qm->pdev->dev;
+ if (unlikely(!acomp_req->src || !acomp_req->slen ||
+ !acomp_req->dst || !acomp_req->dlen))
+ return -EINVAL;
- req = hisi_zip_create_req(qp_ctx, acomp_req);
- if (IS_ERR(req))
- return PTR_ERR(req);
+ if (ctx->fallback)
+ return hisi_zip_fallback_do_work(acomp_req, qp->alg_type);
+
+ ret = hisi_zip_create_req(req);
+ if (ret && (acomp_req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)) {
+ /* all req bitmaps are used add to backlog list */
+ req->req_id = HZIP_INVAL_REQ_ID;
+ hisi_zip_enqueue_backlog(req);
+ return -EBUSY;
+ } else if (unlikely(ret)) {
+ return -ENOSPC;
+ }
- ret = hisi_zip_do_work(qp_ctx, req);
- if (unlikely(ret != -EINPROGRESS)) {
- dev_info_ratelimited(dev, "failed to do compress (%d)!\n", ret);
- hisi_zip_remove_req(qp_ctx, req);
+ ret = hisi_zip_map_req_buffers(req);
+ if (unlikely(ret))
+ goto remove_req;
+
+ ret = hisi_zip_do_work(req);
+ if (ret == -EBUSY && (acomp_req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)) {
+ /* hardwre busy add to backlog list */
+ hisi_zip_enqueue_backlog(req);
+ } else if (unlikely(ret != -EINPROGRESS)) {
+ dev_info_ratelimited(&qp->qm->pdev->dev,
+ "failed to do %scompress (%d)!\n",
+ qp->alg_type ? "de" : "", ret);
+ ret = -ENOSPC;
+ goto unmap_req;
}
return ret;
+
+unmap_req:
+ hisi_zip_unmap_req_buffers(req);
+remove_req:
+ hisi_zip_remove_req(req);
+ return ret;
}
-static int hisi_zip_adecompress(struct acomp_req *acomp_req)
+static int hisi_zip_acompress(struct acomp_req *acomp_req)
{
struct hisi_zip_ctx *ctx = crypto_tfm_ctx(acomp_req->base.tfm);
- struct hisi_zip_qp_ctx *qp_ctx = &ctx->qp_ctx[HZIP_QPC_DECOMP];
- struct hisi_zip_req *req;
- struct device *dev;
- int ret;
-
- if (ctx->fallback)
- return hisi_zip_fallback_do_work(acomp_req, 1);
+ struct hisi_zip_req *req = acomp_request_ctx(acomp_req);
- dev = &qp_ctx->qp->qm->pdev->dev;
-
- req = hisi_zip_create_req(qp_ctx, acomp_req);
- if (IS_ERR(req))
- return PTR_ERR(req);
+ req->req = acomp_req;
+ req->qp_ctx = &ctx->qp_ctx[HZIP_QPC_COMP];
+ return hisi_zip_do_comp(req);
+}
- ret = hisi_zip_do_work(qp_ctx, req);
- if (unlikely(ret != -EINPROGRESS)) {
- dev_info_ratelimited(dev, "failed to do decompress (%d)!\n",
- ret);
- hisi_zip_remove_req(qp_ctx, req);
- }
+static int hisi_zip_adecompress(struct acomp_req *acomp_req)
+{
+ struct hisi_zip_ctx *ctx = crypto_tfm_ctx(acomp_req->base.tfm);
+ struct hisi_zip_req *req = acomp_request_ctx(acomp_req);
- return ret;
+ req->req = acomp_req;
+ req->qp_ctx = &ctx->qp_ctx[HZIP_QPC_DECOMP];
+ return hisi_zip_do_comp(req);
}
static int hisi_zip_decompress(struct acomp_req *acomp_req)
{
- return hisi_zip_fallback_do_work(acomp_req, 1);
+ return hisi_zip_fallback_do_work(acomp_req, HZIP_ALG_TYPE_DECOMP);
}
static const struct hisi_zip_sqe_ops hisi_zip_ops = {
@@ -463,7 +559,7 @@ static int hisi_zip_create_req_q(struct hisi_zip_ctx *ctx)
{
u16 q_depth = ctx->qp_ctx[0].qp->sq_depth;
struct hisi_zip_req_q *req_q;
- int i, ret;
+ int i;
for (i = 0; i < HZIP_CTX_Q_NUM; i++) {
req_q = &ctx->qp_ctx[i].req_q;
@@ -471,43 +567,21 @@ static int hisi_zip_create_req_q(struct hisi_zip_ctx *ctx)
req_q->req_bitmap = bitmap_zalloc(req_q->size, GFP_KERNEL);
if (!req_q->req_bitmap) {
- ret = -ENOMEM;
- if (i == 0)
- return ret;
-
- goto err_free_comp_q;
+ bitmap_free(ctx->qp_ctx[HZIP_QPC_COMP].req_q.req_bitmap);
+ return -ENOMEM;
}
spin_lock_init(&req_q->req_lock);
-
- req_q->q = kzalloc_objs(struct hisi_zip_req, req_q->size);
- if (!req_q->q) {
- ret = -ENOMEM;
- if (i == 0)
- goto err_free_comp_bitmap;
- else
- goto err_free_decomp_bitmap;
- }
}
return 0;
-
-err_free_decomp_bitmap:
- bitmap_free(ctx->qp_ctx[HZIP_QPC_DECOMP].req_q.req_bitmap);
-err_free_comp_q:
- kfree(ctx->qp_ctx[HZIP_QPC_COMP].req_q.q);
-err_free_comp_bitmap:
- bitmap_free(ctx->qp_ctx[HZIP_QPC_COMP].req_q.req_bitmap);
- return ret;
}
static void hisi_zip_release_req_q(struct hisi_zip_ctx *ctx)
{
int i;
- for (i = 0; i < HZIP_CTX_Q_NUM; i++) {
- kfree(ctx->qp_ctx[i].req_q.q);
+ for (i = 0; i < HZIP_CTX_Q_NUM; i++)
bitmap_free(ctx->qp_ctx[i].req_q.req_bitmap);
- }
}
static int hisi_zip_create_sgl_pool(struct hisi_zip_ctx *ctx)
@@ -620,6 +694,7 @@ static struct acomp_alg hisi_zip_acomp_deflate = {
.cra_module = THIS_MODULE,
.cra_priority = HZIP_ALG_PRIORITY,
.cra_ctxsize = sizeof(struct hisi_zip_ctx),
+ .cra_reqsize = sizeof(struct hisi_zip_req),
}
};
@@ -658,6 +733,7 @@ static struct acomp_alg hisi_zip_acomp_lz4 = {
.cra_module = THIS_MODULE,
.cra_priority = HZIP_ALG_PRIORITY,
.cra_ctxsize = sizeof(struct hisi_zip_ctx),
+ .cra_reqsize = sizeof(struct hisi_zip_req),
}
};
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] crypto: hisilicon - improve backlog handling
From: ZongYu Wu @ 2026-05-15 11:45 UTC (permalink / raw)
To: herbert, davem
Cc: linux-kernel, linux-crypto, fanghao11, liulongfang, qianweili,
wangzhou1
From: Chenghai Huang <huangchenghai2@huawei.com>
This series improves backlog handling for HiSilicon crypto drivers.
The ZIP and HPRE drivers are extended to support backlog queuing when
the hardware queue is temporarily busy. Instead of failing requests
immediately under hardware congestion, requests can now be queued and
resubmitted when previous requests complete.
The series also fixes a use-after-free issue in the SEC2 backlog path.
The crypto core may release the request and its tfm context immediately
after crypto_request_complete() returns. The SEC2 driver must therefore
avoid accessing context memory that may already have been freed while
processing backlog requests.
Chenghai Huang (1):
crypto: hisilicon/zip - add backlog support for zip
Wenkai Lin (1):
crypto: hisilicon/sec2 - fix UAF in sec_alg_send_backlog
lizhi (1):
crypto: hisilicon/hpre - implement full backlog support for hpre
driver
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 223 +++++++++++----
drivers/crypto/hisilicon/sec2/sec_crypto.c | 23 +-
drivers/crypto/hisilicon/zip/zip_crypto.c | 286 +++++++++++++-------
3 files changed, 359 insertions(+), 173 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2] crypto: krb5 - filter out async aead implementations at alloc
From: David Howells @ 2026-05-15 11:47 UTC (permalink / raw)
To: Michael Bommarito
Cc: dhowells, Herbert Xu, 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>
Michael Bommarito <michael.bommarito@gmail.com> wrote:
> - ci = crypto_alloc_aead(krb5->encrypt_name, 0, 0);
> + ci = crypto_alloc_aead(krb5->encrypt_name, 0, CRYPTO_ALG_ASYNC);
Apologies, but doesn't that do the opposite of what we want?
Documentation/crypto/architecture.rst says:
The mask flag restricts the type of cipher. The only allowed flag is
CRYPTO_ALG_ASYNC to restrict the cipher lookup function to
asynchronous ciphers. Usually, a caller provides a 0 for the mask
flag.
Don't we want only synchronous ciphers?
David
^ permalink raw reply
* Re: [PATCH v2 0/3] soc: qcom: ice: Enable firmware managed resource
From: Linlin Zhang @ 2026-05-15 11:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Herbert Xu, David S . Miller, devicetree, linux-crypto,
linux-arm-msm, linux-kernel
In-Reply-To: <20260514-provocative-golden-woodpecker-b3e494@quoll>
On 5/14/2026 8:52 PM, Krzysztof Kozlowski wrote:
> On Mon, May 11, 2026 at 08:37:47PM -0700, Linlin Zhang wrote:
>> From: linlzhan <linlzhan@qti.qualcomm.com>
>>
>> The Qualcomm automotive SA8255p SoC relies on firmware to configure
>> platform resources, including clocks, interconnects and TLMM (GPIOs).
>> These resources are controlled by the driver via SCMI power and
>> performance protocols.
>>
>> The SCMI power protocol is used to enable and disable platform
>> resources, including clocks, interconnect paths, and TLMM, by mapping
>> resource state transitions to the runtime PM framework?s
>> resume/suspend callbacks.
>>
>> In this design, the ICE driver acts as an SCMI client, with clocks and
>> power domains abstracted and controlled by the SCMI server in firmware.
>> This implementation depends on pm_runtime_resume_and_get() and
>> pm_runtime_put_sync(), which are available in the OPP tree?s
>> linux-next branch.
>>
>> v2:
>> -- rebase the patchset
>> -- update to/cc lists
>> -- Link to v1: https://lore.kernel.org/all/20260430032136.3058773-1-linlin.zhang@oss.qualcomm.com/
>>
>> -- To Linux Community
>>
>> v6:
>> - Protect calling clock API with fw_managed flag in ICE runtime OPS callbacks.
>> - Link to v5: http://shc-kerarch-hyd:8080/kernel_archive/20260324095703.1306437-1-linlin.zhang@oss.qualcomm.com/T/#t
>
> Please do not include non-working links in public postings.
Thanks for your comment!
I'll remove them in next patch
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 0/2] authencesn: Refactor in-place decryption
From: Scott Guo @ 2026-05-15 11:01 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, Scott GUO
In-Reply-To: <4e9aee15-62e6-4d71-a836-250c5376a8fd@163.com>
Another thought: even with this fix, Fragnesia should still funciton. It
just block current PoCs which pass in the page cache in the position for
auth data.
Avoid changing the auth part would not be enough because attacker would
still be able to link a page cache page within the cryptlen part and
override it with the 4 bytes from sequence number.
在 2026/5/15 18:41, Scott Guo 写道:
> 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 1/2] dt-bindings: crypto: qcom,prng: Document Shikra TRNG
From: Krzysztof Kozlowski @ 2026-05-15 11:00 UTC (permalink / raw)
To: Kuldeep Singh, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260514-shikra_rng-v1-1-4ea721a1429a@oss.qualcomm.com>
On 14/05/2026 15:16, Kuldeep Singh wrote:
> Document shikra compatible for the True Random Number Generator.
>
> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 1 +
> 1 file changed, 1 insertion(+)
Same problems.
Best regards,
Krzysztof
^ permalink raw reply
* 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
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