* Re: [PATCH v5 2/7] x86/msr: add wrmsrq_on_cpus helper
From: Kalra, Ashish @ 2026-05-28 19:55 UTC (permalink / raw)
To: Dave Hansen, Borislav Petkov
Cc: tglx, mingo, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb, pbonzini, aik,
Michael.Roth, KPrateek.Nayak, Tycho.Andersen, Nathan.Fontenot,
ackerleytng, jackyli, pgonda, rientjes, jacobhxu, xin,
pawan.kumar.gupta, babu.moger, dyoung, nikunj, john.allen, darwi,
linux-kernel, linux-crypto, kvm, linux-coco
In-Reply-To: <c40dcb8c-5706-4c0f-ac85-c22957b9e192@intel.com>
Hello Dave,
On 5/28/2026 2:50 PM, Dave Hansen wrote:
> On 5/28/26 12:37, Kalra, Ashish wrote:
>> A simple loop would be perfectly fine and avoids the need for the wrmsrq_on_cpus() helper entirely:
>>
>> for_each_cpu(cpu, &rmpopt_cpumask)
>> wrmsrq_on_cpu(cpu, MSR_AMD64_RMPOPT_BASE, rmpopt_base);
>
> I'm glad we're on the same page finally. I just hope we can get to this
> point more quickly next time. I started off with exactly this
> suggestion, but someone chimed in to the thread and said it was "slower":
>
>> https://lore.kernel.org/lkml/6a50d050-f602-43fd-a44a-cecedd9823eb@amd.com/
>
Yes, actually i should have made it explicitly clear that we need to do it in
parallel especially for issuing the RMPOPT instruction itself, as that is
in a performance critical path (and for that we are using on_each_cpu_mask()).
Thanks,
Ashish
^ permalink raw reply
* Re: [PATCH 0/8] ARM crc64 and XOR using NEON intrinsics
From: Eric Biggers @ 2026-05-28 20:35 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Ard Biesheuvel,
Christoph Hellwig, Russell King, Arnd Bergmann
In-Reply-To: <20260422171655.3437334-10-ardb+git@google.com>
On Wed, Apr 22, 2026 at 07:16:56PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> This is a follow-up to both [0] and [1], both of which included patch #1
> of this series, which introduces the asm/neon-intrinsics.h header on
> 32-bit ARM. The remaining changes rely on this.
>
> The purpose of this series is to streamline / clean up the use of NEON
> intrinsics on 32-bit ARM, by sharing more code, clean up Make rules and
> finally, getting rid of the hacked up types.h header, which does some
> nasty things that are only needed when building NEON intrinsics code.
>
> Patches #2 and #3 replace the ARM autovectorized XOR implementation with
> the NEON intrinsics version used by arm64.
>
> Patches #4 and #5 enable the arm64 NEON intrinsics implementation of
> crc64 on 32-bit ARM.
>
> Patches #6 and #7 drop the direct includes of <arm_neon.h> and perform
> some additional cleanup to reduce the delta between ARM and arm64 code
> and Make rules.
>
> It would probably be easiest to take all these changes through a single
> tree, and the CRC tree seems like a suitable candidate, if Eric agrees.
>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Eric Biggers <ebiggers@kernel.org>
>
> [0] https://lore.kernel.org/all/20260331074940.55502-7-ardb+git@google.com/
> [1] https://lore.kernel.org/all/20260330144630.33026-7-ardb@kernel.org/
>
> Ard Biesheuvel (8):
> ARM: Add a neon-intrinsics.h header like on arm64
> xor/arm: Replace vectorized implementation with arm64's intrinsics
> xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
> lib/crc: Turn NEON intrinsics crc64 implementation into common code
> lib/crc: arm: Enable arm64's NEON intrinsics implementation of crc64
> crypto: aegis128 - Use neon-intrinsics.h on ARM too
> lib/raid6: Include asm/neon-intrinsics.h rather than arm_neon.h
> ARM: Remove hacked-up asm/types.h header
Applied patches 1-6 to
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=crc-next
- Eric
^ permalink raw reply
* [PATCH 0/2] KVM: Miscallenous SEV/SNP fixes
From: Atish Patra @ 2026-05-28 23:11 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini, Borislav Petkov, Dave Hansen,
x86, H. Peter Anvin, Tom Lendacky, Marc Orr, Peter Gonda,
Brijesh Singh, Youngjae Lee, Ashish Kalra, Michael Roth,
John Allen, Herbert Xu
Cc: clm, kvm, linux-kernel, linux-crypto, stable, Atish Patra
This series addresses a few issues found during code audit of the
KVM SEV/SNP and CCP driver code. The fixes include a incorrect lock state
and incomplete state handling during intra-host migration for SNP VMs.
To: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
To: Borislav Petkov <bp@alien8.de>
To: Dave Hansen <dave.hansen@linux.intel.com>
To: x86@kernel.org
To: H. Peter Anvin <hpa@zytor.com>
To: Tom Lendacky <thomas.lendacky@amd.com>
To: Marc Orr <marcorr@google.com>
To: Peter Gonda <pgonda@google.com>
To: Brijesh Singh <brijesh.singh@amd.com>
To: Youngjae Lee <youngjaelee@meta.com>
To: Ashish Kalra <ashish.kalra@amd.com>
To: Michael Roth <michael.roth@amd.com>
To: John Allen <john.allen@amd.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: clm@meta.com
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Atish Patra <atishp@meta.com>
---
Atish Patra (2):
KVM: SEV: Do not allow SEV-SNP VMs from intra-host migration
crypto: ccp: Fix possible deadlock in SEV init failure path
arch/x86/kvm/svm/sev.c | 3 ++-
drivers/crypto/ccp/sev-dev.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
---
base-commit: e7ae89a0c97ce2b68b0983cd01eda67cf373517d
change-id: 20260525-sev_snp_fixes-0b73789c1a91
Best regards,
--
Atish Patra <atishp@meta.com>
^ permalink raw reply
* [PATCH 1/2] KVM: SEV: Do not allow SEV-SNP VMs from intra-host migration
From: Atish Patra @ 2026-05-28 23:11 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini, Borislav Petkov, Dave Hansen,
x86, H. Peter Anvin, Tom Lendacky, Marc Orr, Peter Gonda,
Brijesh Singh, Youngjae Lee, Ashish Kalra, Michael Roth,
John Allen, Herbert Xu
Cc: clm, kvm, linux-kernel, linux-crypto, stable, Atish Patra
In-Reply-To: <20260528-sev_snp_fixes-v1-0-d67a08151779@meta.com>
From: Atish Patra <atishp@meta.com>
The intra-host migration feature is not fully implemented for SEV-SNP
VMs which require additional SNP-specific state such as guest_req_mutex,
guest_req_buf, and guest_resp_buf to be transferred or initialized on
the destination.
Reject SNP source VMs in sev_vm_move_enc_context_from() until proper
SNP state transfer is implemented.
Fixes: 0b020f5af092 ("KVM: SEV: Add support for SEV-ES intra host migration")
Reported-by: Chris Mason <clm@meta.com>
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Atish Patra <atishp@meta.com>
---
arch/x86/kvm/svm/sev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index c2126b3c3072..aff6a0cf5bfe 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2142,7 +2142,8 @@ int sev_vm_move_enc_context_from(struct kvm *kvm, unsigned int source_fd)
return ret;
if (kvm->arch.vm_type != source_kvm->arch.vm_type ||
- sev_guest(kvm) || !sev_guest(source_kvm)) {
+ sev_guest(kvm) || !sev_guest(source_kvm) ||
+ sev_snp_guest(source_kvm)) {
ret = -EINVAL;
goto out_unlock;
}
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH 2/2] crypto: ccp: Fix possible deadlock in SEV init failure path
From: Atish Patra @ 2026-05-28 23:11 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini, Borislav Petkov, Dave Hansen,
x86, H. Peter Anvin, Tom Lendacky, Marc Orr, Peter Gonda,
Brijesh Singh, Youngjae Lee, Ashish Kalra, Michael Roth,
John Allen, Herbert Xu
Cc: clm, kvm, linux-kernel, linux-crypto, stable, Atish Patra
In-Reply-To: <20260528-sev_snp_fixes-v1-0-d67a08151779@meta.com>
From: Atish Patra <atishp@meta.com>
__sev_platform_init_handle_init_ex_path() called
rmp_mark_pages_firmware() with locked=false but while the parent
function of init_ex_path already acquired the sev_cmd_mutex.
In case of a rmpupdate failure for any page after the first, the cleanup
path would invoke reclaim pages which would result in a deadlock in
sev_do_cmd.
Pass locked=true to honor the lock status of the parent function.
Fixes: 7364a6fbca45 ("crypto: ccp: Handle non-volatile INIT_EX data when SNP is enabled")
Reported-by: Chris Mason <clm@meta.com>
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Atish Patra <atishp@meta.com>
---
drivers/crypto/ccp/sev-dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index d1e9e0ac63b6..3d4793e8e34b 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -1557,7 +1557,7 @@ static int __sev_platform_init_handle_init_ex_path(struct sev_device *sev)
unsigned long npages;
npages = 1UL << get_order(NV_LENGTH);
- if (rmp_mark_pages_firmware(__pa(sev_init_ex_buffer), npages, false)) {
+ if (rmp_mark_pages_firmware(__pa(sev_init_ex_buffer), npages, true)) {
dev_err(sev->dev, "SEV: INIT_EX NV memory page state change failed.\n");
return -ENOMEM;
}
--
2.53.0-Meta
^ permalink raw reply related
* Re: [PATCH net-next 0/6] Remove unused support for crypto tfm cloning
From: Herbert Xu @ 2026-05-28 23:23 UTC (permalink / raw)
To: Eric Biggers
Cc: netdev, linux-crypto, linux-kernel, Eric Dumazet, Neal Cardwell,
Kuniyuki Iwashima, David S . Miller, David Ahern, Jakub Kicinski,
Paolo Abeni, Simon Horman, Ard Biesheuvel, Jason A . Donenfeld,
Dmitry Safonov
In-Reply-To: <20260522053028.91165-1-ebiggers@kernel.org>
On Fri, May 22, 2026 at 12:30:22AM -0500, Eric Biggers wrote:
> This series is targeting net-next because it depends on
> "net/tcp: Remove tcp_sigpool". So far no commits in cryptodev conflict
> with this, so I suggest that this be taken through net-next for 7.2.
>
> This series removes support for transformation cloning from the crypto
> API. Now that the TCP-AO and TCP-MD5 code no longer uses it, it no
> longer has a user. And it's unlikely that a new one will appear, as the
> library API solves the problem in a much simpler and more efficient way.
>
> This feature also regressed performance for all crypto API users, since
> it changed crypto transformation objects into reference-counted objects.
> That added expensive atomic operations. The refcount is reverted by
> this series, thus fixing the performance regression.
>
> A subset of this was previously sent in
> https://lore.kernel.org/r/20260307224341.5644-1-ebiggers@kernel.org
> Compared to that version, this version is a bit more comprehensive.
>
> Eric Biggers (6):
> crypto: hash - Remove support for cloning hash tfms
> crypto: cipher - Remove crypto_clone_cipher()
> crypto: api - Remove crypto_clone_tfm()
> crypto: api - Remove per-tfm refcount
> crypto: api - Fold __crypto_alloc_tfmgfp() into __crypto_alloc_tfm()
> crypto: api - Fold crypto_alloc_tfmmem() into crypto_create_tfm_node()
>
> crypto/ahash.c | 70 -----------------------------
> crypto/api.c | 76 +++++---------------------------
> crypto/cipher.c | 28 ------------
> crypto/cmac.c | 16 -------
> crypto/cryptd.c | 16 -------
> crypto/hmac.c | 31 -------------
> crypto/internal.h | 10 -----
> crypto/shash.c | 37 ----------------
> include/crypto/hash.h | 8 ----
> include/crypto/internal/cipher.h | 2 -
> include/linux/crypto.h | 1 -
> 11 files changed, 10 insertions(+), 285 deletions(-)
>
>
> base-commit: 1a1f055318d82e64485a6ff8420e5f70b4267998
> --
> 2.54.0
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
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 v5 4/7] x86/sev: Add support to perform RMP optimizations asynchronously
From: Kalra, Ashish @ 2026-05-28 23:52 UTC (permalink / raw)
To: Ackerley Tng, tglx, mingo, bp, dave.hansen, x86, hpa, seanjc,
peterz, thomas.lendacky, herbert, davem, ardb
Cc: pbonzini, aik, Michael.Roth, KPrateek.Nayak, Tycho.Andersen,
Nathan.Fontenot, jackyli, pgonda, rientjes, jacobhxu, xin,
pawan.kumar.gupta, babu.moger, dyoung, nikunj, john.allen, darwi,
linux-kernel, linux-crypto, kvm, linux-coco
In-Reply-To: <CAEvNRgGfyb7zvZ1u1j7YLomD+JdAxnVW36gtvNG9gxgZ80vMyQ@mail.gmail.com>
Hello Ackerley,
On 5/28/2026 9:45 AM, Ackerley Tng wrote:
> Ashish Kalra <Ashish.Kalra@amd.com> writes:
>
> Thank you Ashish!
>
>> From: Ashish Kalra <ashish.kalra@amd.com>
>>
>> When SEV-SNP is enabled, all writes to memory are checked to ensure
>> integrity of SNP guest memory. This imposes performance overhead on the
>> whole system.
>>
>> RMPOPT is a new instruction that minimizes the performance overhead of
>> RMP checks on the hypervisor and on non-SNP guests by allowing RMP
>> checks to be skipped for 1GB regions of memory that are known not to
>> contain any SEV-SNP guest memory.
>>
>> Add support for performing RMP optimizations asynchronously using a
>> dedicated workqueue.
>>
>> Enable RMPOPT optimizations globally for all system RAM up to 2TB at
>
> This should also be updated to say "Enable RMPOPT optimizations for up
> to 2TB worth of system RAM at..."
>
> The current phrasing sounds like only addresses [0, 2TB) are allowed to
> be optimized, but actually any address [start, start + 2TB) can be
> optimized?
Yes, i will update it.
>
>> RMP initialization time. RMP checks can initially be skipped for 1GB
>> memory ranges that do not contain SEV-SNP guest memory (excluding
>> preassigned pages such as the RMP table and firmware pages). As SNP
>> guests are launched, RMPUPDATE will disable the corresponding RMPOPT
>> optimizations.
>>
>> Suggested-by: Thomas Lendacky <thomas.lendacky@amd.com>
>> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
>> Reviewed-by: Ackerley Tng <ackerleytng@google.com>
>> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
>> ---
>> arch/x86/virt/svm/sev.c | 167 +++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 164 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
>> index 82f9dc7a57c3..8876cac052d5 100644
>> --- a/arch/x86/virt/svm/sev.c
>> +++ b/arch/x86/virt/svm/sev.c
>> @@ -19,6 +19,7 @@
>> #include <linux/iommu.h>
>> #include <linux/amd-iommu.h>
>> #include <linux/nospec.h>
>> +#include <linux/workqueue.h>
>>
>> #include <asm/sev.h>
>> #include <asm/processor.h>
>> @@ -125,7 +126,18 @@ static void *rmp_bookkeeping __ro_after_init;
>> static u64 probed_rmp_base, probed_rmp_size;
>>
>> static cpumask_t rmpopt_cpumask;
>> -static phys_addr_t rmpopt_pa_start;
>> +static phys_addr_t rmpopt_pa_start, rmpopt_pa_end;
>> +
>> +enum rmpopt_function {
>> + RMPOPT_FUNC_VERIFY_AND_REPORT_STATUS,
>> + RMPOPT_FUNC_REPORT_STATUS
>> +};
>> +
>> +#define RMPOPT_WORK_TIMEOUT 10000
>> +
>> +static struct workqueue_struct *rmpopt_wq;
>> +static struct delayed_work rmpopt_delayed_work;
>> +static DEFINE_MUTEX(rmpopt_wq_mutex);
>>
>> static LIST_HEAD(snp_leaked_pages_list);
>> static DEFINE_SPINLOCK(snp_leaked_pages_list_lock);
>> @@ -564,12 +576,21 @@ EXPORT_SYMBOL_FOR_MODULES(snp_prepare, "ccp");
>>
>> static void rmpopt_cleanup(void)
>> {
>> + guard(mutex)(&rmpopt_wq_mutex);
>> +
>> + if (!rmpopt_wq)
>> + return;
>> +
>> + cancel_delayed_work_sync(&rmpopt_delayed_work);
>> + destroy_workqueue(rmpopt_wq);
>> +
>> cpus_read_lock();
>> wrmsrq_on_cpus(&rmpopt_cpumask, MSR_AMD64_RMPOPT_BASE, 0);
>> cpus_read_unlock();
>>
>> cpumask_clear(&rmpopt_cpumask);
>> - rmpopt_pa_start = 0;
>> + rmpopt_pa_start = rmpopt_pa_end = 0;
>> + rmpopt_wq = NULL;
>> }
>>
>> void snp_shutdown(void)
>> @@ -587,6 +608,105 @@ void snp_shutdown(void)
>> }
>> EXPORT_SYMBOL_FOR_MODULES(snp_shutdown, "ccp");
>>
>> +static inline bool __rmpopt(u64 rax, u64 rcx)
>
> Perhaps use pa_start instead of rax and op_type for rcx?
>
I used these parameters to align with the RMPOPT specifications (rax and rcx)
which i think makes more sense.
>> +{
>> + bool optimized;
>> +
>> + asm volatile(".byte 0xf2, 0x0f, 0x01, 0xfc"
>> + : "=@ccc" (optimized)
>> + : "a" (rax), "c" (rcx)
>> + : "memory", "cc");
>> +
>> + return optimized;
>> +}
>> +
>> +static void rmpopt(u64 pa)
>> +{
>> + u64 rax = ALIGN_DOWN(pa, SZ_1G);
>> + u64 rcx = RMPOPT_FUNC_VERIFY_AND_REPORT_STATUS;
>> +
>
> And pa_start and op_type here too.
>
>> + __rmpopt(rax, rcx);
>> +}
>> +
>> +/*
>> + * 'val' is a system physical address.
>> + */
>> +static void rmpopt_smp(void *val)
>> +{
>> + rmpopt((u64)val);
>> +}
>> +
>> +/*
>> + * RMPOPT optimizations skip RMP checks at 1GB granularity if this
>> + * range of memory does not contain any SNP guest memory.
>> + */
>> +static void rmpopt_work_handler(struct work_struct *work)
>> +{
>> + bool current_cpu_cleared = false;
>> + phys_addr_t pa;
>> + int this_cpu;
>> +
>> + pr_info("Attempt RMP optimizations on physical address range @1GB alignment [0x%016llx - 0x%016llx]\n",
>> + rmpopt_pa_start, rmpopt_pa_end);
>> +
>> + /*
>> + * RMPOPT scans the RMP table, stores the result of the scan in the
>> + * reserved processor memory. The RMP scan is the most expensive
>> + * part. If a second RMPOPT occurs, it can skip the expensive scan
>> + * if they can see a cached result in the reserved processor memory.
>> + *
>> + * Do RMPOPT on one CPU alone. Then, follow that up with RMPOPT
>> + * on every other primary thread. This potentially allows the
>
> I like the leader and follower comments below, thanks! With this
> leader/follower setup, will the followers definitely see the cached scan
> results, or might the followers still potentially not benefit from the
> caching? If it's still only "potentially", why?
I am verifying with the H/W architects if this is always going to be true or not,
will the followers always benefit from the scan results cached by the leader (first CPU)
or there is a possibility that the followers cannot see/access/get the cached results
and instead do full RMP scanning ?
>
>> + * followers to use the "cached" scan results to avoid repeating
>> + * full scans.
>> + */
>> +
>> + /*
>> + * Pin the worker to the current CPU for the leader loop so that
>> + * this_cpu remains valid and the RMPOPT instruction executes on
>> + * the CPU that was cleared from the cpumask. The workqueue is
>> + * WQ_UNBOUND, so without pinning, the scheduler could migrate
>> + * the worker between the cpumask manipulation and the leader
>> + * loop, causing the leader to run on a different CPU while
>> + * this_cpu's core is skipped entirely.
>> + *
>> + * Use migrate_disable() rather than get_cpu() to prevent
>> + * migration while still allowing preemption.
>> + *
>> + * Note: rmpopt_cpumask is modified here without holding
>> + * rmpopt_wq_mutex. This is safe because the delayed_work
>> + * mechanism guarantees single-threaded execution of this
>> + * handler, and rmpopt_cleanup() calls cancel_delayed_work_sync()
>> + * to ensure handler completion before tearing down the cpumask.
>> + */
>> + migrate_disable();
>> + this_cpu = smp_processor_id();
>> + if (cpumask_test_cpu(this_cpu, &rmpopt_cpumask)) {
>> + cpumask_clear_cpu(this_cpu, &rmpopt_cpumask);
>> + current_cpu_cleared = true;
>> + }
>> +
>
> Instead of reusing the global rmpopt_cpumask, why not make a copy of
> rmpopt_cpumask for this function? Then this function won't have to
> figure out current_cpu_cleared or restore rmpopt_cpumask at the end.
>
> I'm thinking to also drop the test and clear, this function can just
> always clear, like
>
> cpumask_clear_cpu(smp_processor_id(), followers_cpumask);
>
> and later
>
> on_each_cpu_mask(&followers_cpumask, ...);
That's surely a much cleaner approach. Instead of modifying global
rmpopt_cpumask and using a local copy:
cpumask_var_t follower_mask;
alloc_cpumask_var(&follower_mask, GFP_KERNEL);
cpumask_copy(follower_mask, &rmpopt_cpumask);
migrate_disable();
this_cpu = smp_processor_id();
cpumask_clear_cpu(this_cpu, follower_mask); // modify local only
// leader loop on this_cpu...
migrate_enable();
// follower loop with follower_mask...
on_each_cpu_mask(follower_mask, rmpopt_smp, ...);
free_cpumask_var(follower_mask);
This eliminates:
- current_cpu_cleared variable
- The restore at the end
Additionally, the global rmpopt_cpumask is never modified, so no concurrency concerns with debugfs or other readers.
>
> Actually, if for whatever reason cpumask_test_cpu(this_cpu,
> &rmpopt_cpumask) above returns false, would that mean somehow some cpu
> exists that wasn't enabled right when rmpopt was initialized?
The work handler can always execute on a cpu which is not in the rmpopt_cpumask, so i believe the
cpumask_test_cpu() needs to be there.
The leader loop must only run on a CPU that has RMPOPT_BASE MSR programmed. If the WQ_UNBOUND scheduler puts the
handler on a CPU not in rmpopt_cpumask, that CPU's core never had RMPOPT enabled -> RMPOPT instruction causes #UD.
So the leader should be conditional:
cpumask_copy(follower_mask, &rmpopt_cpumask);
migrate_disable();
this_cpu = smp_processor_id();
if (cpumask_test_cpu(this_cpu, follower_mask)) {
cpumask_clear_cpu(this_cpu, follower_mask);
/* Leader: prime the RMPOPT cache on this CPU */
for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G)
rmpopt(pa);
}
migrate_enable();
/* Followers: run RMPOPT on remaining cores */
cpus_read_lock();
for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G) {
on_each_cpu_mask(follower_mask, rmpopt_smp, (void *)pa, true);
cond_resched();
}
cpus_read_unlock();
If the current CPU isn't in rmpopt_cpumask, the leader is skipped and all cores run as followers — they lose the caching
optimization from a leader priming pass, but correctness is maintained.
Alternatively, i could pick the first CPU from rmpopt_cpumask as the explicit leader instead of relying on whichever CPU the
scheduler chose.
cpumask_copy(follower_mask, &rmpopt_cpumask);
migrate_disable();
this_cpu = smp_processor_id();
if (cpumask_test_cpu(this_cpu, follower_mask)) {
/* Fast path: leader runs locally, no IPIs */
cpumask_clear_cpu(this_cpu, follower_mask);
for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G)
rmpopt(pa);
} else {
/*
* Current CPU does not have RMPOPT_BASE MSR programmed.
* Pick an explicit leader from the cpumask to avoid #UD.
*/
int leader_cpu = cpumask_first(follower_mask);
cpumask_clear_cpu(leader_cpu, follower_mask);
for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G)
smp_call_function_single(leader_cpu, rmpopt_smp,
(void *)pa, true);
}
migrate_enable();
/* Followers: run RMPOPT on remaining cores */
cpus_read_lock();
for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G) {
on_each_cpu_mask(follower_mask, rmpopt_smp,
(void *)pa, true);
/* Give a chance for other threads to run */
cond_resched();
}
cpus_read_unlock();
free_cpumask_var(follower_mask);
}
> If yes, what happens if we call rmpopt() on a cpu where it wasn't initialized?
That will cause a #UD exception, if RMPOPT instruction is issued on
a CPU where RMPOPT is not enabled (RMPOPT_BASE.RMPOPT_EN==0), so
it is essential to issue RMPOPT instruction only on the cpumask (covers both
primary and secondary threads) which was setup initially when rmpopt was
initialized and on which the RMPOPT_BASE MSR was setup and RMPOPT enabled.
I believe, there are actually three cases to be considered here:
1. Current CPU is in rmpopt_cpumask -> primary thread, run leader locally, remove from followers
2. Current CPU's sibling is in rmpopt_cpumask -> sibling thread, RMPOPT_BASE per-core is programmed, run leader locally,
remove the sibling's primary from the follower mask
3. Neither -> new/unknown CPU, RMPOPT_BASE never programmed on this core, fall back to explicit leader via IPI.
So this seems to the *correct* implementation of the RMPOPT loop:
cpumask_copy(follower_mask, &rmpopt_cpumask);
migrate_disable();
this_cpu = smp_processor_id();
if (cpumask_test_cpu(this_cpu, follower_mask)) {
/*
* Current CPU is a primary thread in rmpopt_cpumask.
* Run leader locally and remove from follower mask.
*/
cpumask_clear_cpu(this_cpu, follower_mask);
for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G)
rmpopt(pa);
} else if (cpumask_intersects(topology_sibling_cpumask(this_cpu),
follower_mask)) {
/*
* Current CPU is a sibling thread whose primary is in
* rmpopt_cpumask. RMPOPT_BASE MSR is per-core, so it
* is safe to run the leader locally. Remove the sibling's
* primary from the follower mask as this core is already
* covered by the leader.
*/
cpumask_andnot(follower_mask, follower_mask,
topology_sibling_cpumask(this_cpu));
for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G)
rmpopt(pa);
} else {
/*
* Current CPU's core does not have RMPOPT_BASE MSR
* programmed. Pick an explicit leader from the cpumask
* to avoid #UD.
*/
int leader_cpu = cpumask_first(follower_mask);
cpumask_clear_cpu(leader_cpu, follower_mask);
for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G)
smp_call_function_single(leader_cpu, rmpopt_smp,
(void *)pa, true);
}
migrate_enable();
/* Followers: run RMPOPT on remaining cores */
cpus_read_lock();
for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G) {
on_each_cpu_mask(follower_mask, rmpopt_smp,
(void *)pa, true);
/* Give a chance for other threads to run */
cond_resched();
}
cpus_read_unlock();
free_cpumask_var(follower_mask);
}
Thanks,
Ashish
>
>> + /* Leader: prime the RMPOPT cache on this CPU */
>> + for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G)
>> + rmpopt(pa);
>> +
>> + migrate_enable();
>> +
>> + /* Followers: run RMPOPT on all other cores */
>> + cpus_read_lock();
>> + for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G) {
>> + on_each_cpu_mask(&rmpopt_cpumask, rmpopt_smp,
>> + (void *)pa, true);
>> +
>> + /* Give a chance for other threads to run */
>> + cond_resched();
>> + }
>> + cpus_read_unlock();
>> +
>> + if (current_cpu_cleared)
>> + cpumask_set_cpu(this_cpu, &rmpopt_cpumask);
>> +}
>> +
>>
>> [...snip...]
>>
^ permalink raw reply
* Re: [PATCH v5 2/7] x86/msr: add wrmsrq_on_cpus helper
From: Borislav Petkov @ 2026-05-29 0:26 UTC (permalink / raw)
To: Kalra, Ashish
Cc: Dave Hansen, tglx, mingo, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb, pbonzini, aik,
Michael.Roth, KPrateek.Nayak, Tycho.Andersen, Nathan.Fontenot,
ackerleytng, jackyli, pgonda, rientjes, jacobhxu, xin,
pawan.kumar.gupta, babu.moger, dyoung, nikunj, john.allen, darwi,
linux-kernel, linux-crypto, kvm, linux-coco
In-Reply-To: <3334a64a-9a5e-4ad5-94f3-01fef788df2e@amd.com>
On Thu, May 28, 2026 at 02:55:44PM -0500, Kalra, Ashish wrote:
> Hello Dave,
>
> On 5/28/2026 2:50 PM, Dave Hansen wrote:
> > On 5/28/26 12:37, Kalra, Ashish wrote:
> >> A simple loop would be perfectly fine and avoids the need for the wrmsrq_on_cpus() helper entirely:
> >>
> >> for_each_cpu(cpu, &rmpopt_cpumask)
> >> wrmsrq_on_cpu(cpu, MSR_AMD64_RMPOPT_BASE, rmpopt_base);
> >
> > I'm glad we're on the same page finally. I just hope we can get to this
> > point more quickly next time. I started off with exactly this
> > suggestion, but someone chimed in to the thread and said it was "slower":
> >
> >> https://lore.kernel.org/lkml/6a50d050-f602-43fd-a44a-cecedd9823eb@amd.com/
> >
>
> Yes, actually i should have made it explicitly clear that we need to do it in
> parallel especially for issuing the RMPOPT instruction itself, as that is
> in a performance critical path (and for that we are using on_each_cpu_mask()).
So which is it? Do we need the wrmsrq_on_cpus() helper or not?
I'm confused.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v5 2/7] x86/msr: add wrmsrq_on_cpus helper
From: Kalra, Ashish @ 2026-05-29 0:29 UTC (permalink / raw)
To: Borislav Petkov
Cc: Dave Hansen, tglx, mingo, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb, pbonzini, aik,
Michael.Roth, KPrateek.Nayak, Tycho.Andersen, Nathan.Fontenot,
ackerleytng, jackyli, pgonda, rientjes, jacobhxu, xin,
pawan.kumar.gupta, babu.moger, dyoung, nikunj, john.allen, darwi,
linux-kernel, linux-crypto, kvm, linux-coco
In-Reply-To: <20260529002613.GEahjdJRsX2uNz0GnH@fat_crate.local>
On 5/28/2026 7:26 PM, Borislav Petkov wrote:
> On Thu, May 28, 2026 at 02:55:44PM -0500, Kalra, Ashish wrote:
>> Hello Dave,
>>
>> On 5/28/2026 2:50 PM, Dave Hansen wrote:
>>> On 5/28/26 12:37, Kalra, Ashish wrote:
>>>> A simple loop would be perfectly fine and avoids the need for the wrmsrq_on_cpus() helper entirely:
>>>>
>>>> for_each_cpu(cpu, &rmpopt_cpumask)
>>>> wrmsrq_on_cpu(cpu, MSR_AMD64_RMPOPT_BASE, rmpopt_base);
>>>
>>> I'm glad we're on the same page finally. I just hope we can get to this
>>> point more quickly next time. I started off with exactly this
>>> suggestion, but someone chimed in to the thread and said it was "slower":
>>>
>>>> https://lore.kernel.org/lkml/6a50d050-f602-43fd-a44a-cecedd9823eb@amd.com/
>>>
>>
>> Yes, actually i should have made it explicitly clear that we need to do it in
>> parallel especially for issuing the RMPOPT instruction itself, as that is
>> in a performance critical path (and for that we are using on_each_cpu_mask()).
>
> So which is it? Do we need the wrmsrq_on_cpus() helper or not?
>
> I'm confused.
>
No, we don't need it, i will drop this helper function patch.
Thanks,
Ashish
^ permalink raw reply
* Re: [PATCH net-next 0/6] Remove unused support for crypto tfm cloning
From: patchwork-bot+netdevbpf @ 2026-05-29 0:50 UTC (permalink / raw)
To: Eric Biggers
Cc: netdev, linux-crypto, linux-kernel, edumazet, ncardwell, kuniyu,
davem, dsahern, kuba, pabeni, horms, ardb, Jason, herbert,
0x7f454c46
In-Reply-To: <20260522053028.91165-1-ebiggers@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 22 May 2026 00:30:22 -0500 you wrote:
> This series is targeting net-next because it depends on
> "net/tcp: Remove tcp_sigpool". So far no commits in cryptodev conflict
> with this, so I suggest that this be taken through net-next for 7.2.
>
> This series removes support for transformation cloning from the crypto
> API. Now that the TCP-AO and TCP-MD5 code no longer uses it, it no
> longer has a user. And it's unlikely that a new one will appear, as the
> library API solves the problem in a much simpler and more efficient way.
>
> [...]
Here is the summary with links:
- [net-next,1/6] crypto: hash - Remove support for cloning hash tfms
https://git.kernel.org/netdev/net-next/c/f331c7be97ce
- [net-next,2/6] crypto: cipher - Remove crypto_clone_cipher()
https://git.kernel.org/netdev/net-next/c/cb2e6e86ceb5
- [net-next,3/6] crypto: api - Remove crypto_clone_tfm()
https://git.kernel.org/netdev/net-next/c/590a46c68a7b
- [net-next,4/6] crypto: api - Remove per-tfm refcount
https://git.kernel.org/netdev/net-next/c/3065170bfc7f
- [net-next,5/6] crypto: api - Fold __crypto_alloc_tfmgfp() into __crypto_alloc_tfm()
https://git.kernel.org/netdev/net-next/c/9d58d14e3a18
- [net-next,6/6] crypto: api - Fold crypto_alloc_tfmmem() into crypto_create_tfm_node()
https://git.kernel.org/netdev/net-next/c/0200de9d75b1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] crypto: algif_skcipher - snapshot IV for async skcipher requests
From: Herbert Xu @ 2026-05-29 5:13 UTC (permalink / raw)
To: Max Clinton; +Cc: linux-crypto, linux-kernel, gregkh, davem, security, stable
In-Reply-To: <20260518233538.705966-2-maxtclinton@gmail.com>
On Mon, May 18, 2026 at 07:35:39PM -0400, Max Clinton wrote:
>
> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> index ba0a17fd9..519ff8d17 100644
> --- a/crypto/algif_skcipher.c
> +++ b/crypto/algif_skcipher.c
> @@ -23,6 +23,7 @@
> * the RX SGL release.
> */
>
> +#include <crypto/internal/skcipher.h>
There is no need for the internal header.
> @@ -116,10 +119,14 @@ static int _skcipher_recvmsg(struct socket *sock, struct msghdr *msg,
>
> /* Allocate cipher request for current operation. */
> areq = af_alg_alloc_areq(sk, sizeof(struct af_alg_async_req) +
> - crypto_skcipher_reqsize(tfm));
> + crypto_skcipher_reqsize(tfm) + ivsize);
> if (IS_ERR(areq))
> return PTR_ERR(areq);
>
> + iv = (u8 *)skcipher_request_ctx(&areq->cra_u.skcipher_req) +
> + crypto_skcipher_reqsize(tfm);
You can rewrite this as
iv = (u8 *)(areq + 1) + crypto_skcipher_reqsize(tfm);
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 0/6] crypto: hisilicon/qm - support function reset and VF isolation
From: Herbert Xu @ 2026-05-29 5:59 UTC (permalink / raw)
To: ZongYu Wu
Cc: davem, linux-kernel, linux-crypto, fanghao11, liulongfang,
qianweili, wangzhou1, huangchenghai2
In-Reply-To: <20260518142956.3593934-1-wuzongyu1@huawei.com>
On Mon, May 18, 2026 at 10:29:50PM +0800, ZongYu Wu wrote:
> This patch set adds function reset and function isolation capabilities,
> and fixes issues related to reset operations.
>
> 1.Currently, the device only supports global reset when an error occurs.
> However, some errors only affect a single function's operation without
> affecting other functions. Therefore, the PF can notify the VF driver
> to perform a reset, rather than using a global reset that affects all
> task.
> 2.When device reset fails or the reset frequency exceeds the
> user-configured threshold, the device on the physical machine will
> be isolated. Add functionality for devices in virtual machines to
> obtain the isolation status of the PF.
> 3.Support for doorbell enable control, which disables doorbell before
> reset and enables doorbell after device initialization.
>
> Weili Qian (2):
> crypto: hisilicon/qm - disable error report before flr
> crypto: hisilicon - mask all error type when removing driver
>
> Zhushuai Yin (3):
> crypto: hisilicon/qm - allow VF devices to query hardware isolation
> status
> crypto: hisilicon/qm - place the interrupt status interface after the
> PM usage counter
> crypto: hisilicon/qm - support function-level error reset
>
> Zongyu Wu (1):
> crypto: hisilicon/qm - support doorbell enable control
>
> drivers/crypto/hisilicon/hpre/hpre_main.c | 19 +-
> drivers/crypto/hisilicon/qm.c | 334 ++++++++++++++++++----
> drivers/crypto/hisilicon/sec2/sec_main.c | 13 +-
> drivers/crypto/hisilicon/zip/zip_main.c | 20 +-
> include/linux/hisi_acc_qm.h | 15 +-
> 5 files changed, 308 insertions(+), 93 deletions(-)
>
> --
> 2.33.0
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] crypto: inside-secure/eip93 - Drop superfluous blank line
From: Herbert Xu @ 2026-05-29 6:00 UTC (permalink / raw)
To: Aleksander Jan Bajkowski
Cc: ansuelsmth, atenart, davem, linux-crypto, linux-kernel
In-Reply-To: <20260518212304.290520-1-olek2@wp.pl>
On Mon, May 18, 2026 at 11:22:56PM +0200, Aleksander Jan Bajkowski wrote:
> No need for a blank line.
>
> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
> ---
> drivers/crypto/inside-secure/eip93/eip93-main.c | 1 -
> 1 file changed, 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: inside-secure/eip93 - Add check for devm_request_threaded_irq
From: Herbert Xu @ 2026-05-29 6:00 UTC (permalink / raw)
To: Aleksander Jan Bajkowski
Cc: ansuelsmth, atenart, davem, linux-crypto, linux-kernel
In-Reply-To: <20260518212506.292170-1-olek2@wp.pl>
On Mon, May 18, 2026 at 11:24:59PM +0200, Aleksander Jan Bajkowski wrote:
> As the potential failure of the devm_request_threaded_irq(),
> it should be better to check the return value and return
> error if fails.
>
> Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support")
> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
> ---
> drivers/crypto/inside-secure/eip93/eip93-main.c | 2 ++
> 1 file changed, 2 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: ecrdsa - remove empty sig_alg exit callback
From: Herbert Xu @ 2026-05-29 6:01 UTC (permalink / raw)
To: Thorsten Blum
Cc: Lukas Wunner, Ignat Korchagin, David S. Miller, linux-crypto,
linux-kernel
In-Reply-To: <20260519083630.147673-3-thorsten.blum@linux.dev>
On Tue, May 19, 2026 at 10:36:32AM +0200, Thorsten Blum wrote:
> ecrdsa_exit_tfm() is empty, and sig_alg .exit is optional. The
> corresponding .init callback is not set either, so there is nothing to
> release in .exit.
>
> Remove the empty function and leave .exit unset.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> crypto/ecrdsa.c | 5 -----
> 1 file changed, 5 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 0/3] crypto - Rework i2c_device_id initialisation
From: Herbert Xu @ 2026-05-29 6:02 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Thorsten Blum, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Ard Biesheuvel, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <cover.1779260113.git.u.kleine-koenig@baylibre.com>
On Wed, May 20, 2026 at 09:01:27AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Hello,
>
> this is v2 of the patch available at
> https://lore.kernel.org/linux-crypto/20260519141033.1586036-2-u.kleine-koenig@baylibre.com.
>
> Changes since v1 are:
>
> - Rebase to next-20260519 to account for changes since v7.1-rc1 (= the
> previous base)
> - Patch #1 is new
> - The adaption to atmel-sha204a is a bit less trivial, so split into a
> separate patch (#2)
>
> Best regards
> Uwe
>
> Uwe Kleine-König (The Capable Hub) (3):
> crypto: atmel-sha204a - Drop of_device_id data
> crypto: atmel-sha204a - Use named initializers for struct
> i2c_device_id
> crypto: atmel-ecc - Use named initializers for struct i2c_device_id
>
> drivers/crypto/atmel-ecc.c | 4 ++--
> drivers/crypto/atmel-sha204a.c | 8 ++++----
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
>
> base-commit: 6a50ba100ace43f43c87384367eb2d2605fcc16c
> --
> 2.47.3
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] s390: crypto: add select CRYPTO_AEAD for aes
From: Herbert Xu @ 2026-05-29 6:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Harald Freudenberger, Holger Dengler,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev, Patrick Steuer,
Arnd Bergmann, Christian Borntraeger, Sven Schnelle, Eric Biggers,
Ard Biesheuvel, linux-crypto, linux-s390, linux-kernel
In-Reply-To: <20260520073911.843561-1-arnd@kernel.org>
On Wed, May 20, 2026 at 09:38:44AM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The aes driver registers both skcipher and aead algorithms,
> but when aead is not enabled this causes a link failure:
>
> s390-linux-ld: arch/s390/crypto/aes_s390.o: in function `aes_s390_fini':
> arch/s390/crypto/aes_s390.c:969:(.text+0x115e): undefined reference to `crypto_unregister_aead'
> s390-linux-ld: arch/s390/crypto/aes_s390.o: in function `aes_s390_init':
> arch/s390/crypto/aes_s390.c:1028:(.init.text+0x294): undefined reference to `crypto_register_aead'
>
> Add the missing 'select' statement.
>
> Fixes: bf7fa038707c ("s390/crypto: add s390 platform specific aes gcm support.")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/s390/crypto/Kconfig | 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] crypto: octeontx - use strscpy_pad in ucode_load_store
From: Herbert Xu @ 2026-05-29 6:06 UTC (permalink / raw)
To: Thorsten Blum
Cc: Srujana Challa, Bharat Bhushan, David S. Miller, Kees Cook,
linux-crypto, linux-kernel
In-Reply-To: <20260520100031.246078-2-thorsten.blum@linux.dev>
On Wed, May 20, 2026 at 12:00:30PM +0200, Thorsten Blum wrote:
> Instead of zero-initializing the temporary buffer and then copying into
> it with strscpy(), use strscpy_pad() to copy the string and zero-pad any
> trailing bytes. Drop the explicit size argument to further simplify the
> code since strscpy_pad() can determine it automatically when the
> destination buffer has a fixed length.
>
> Also use strscpy_pad() to check for string truncation instead of the
> hard-coded OTX_CPT_UCODE_NAME_LENGTH.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c | 5 ++---
> 1 file changed, 2 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] crypto: qat - fix restarting state leak on allocation failure
From: Herbert Xu @ 2026-05-29 6:06 UTC (permalink / raw)
To: Ahsan Atta
Cc: linux-crypto, qat-linux, stable, Maksim Lukoshkov,
Giovanni Cabiddu
In-Reply-To: <20260520123300.210290-1-ahsan.atta@intel.com>
On Wed, May 20, 2026 at 01:33:00PM +0100, Ahsan Atta wrote:
> In adf_dev_aer_schedule_reset(), ADF_STATUS_RESTARTING is set before
> allocating reset_data. If the allocation fails, the function returns
> -ENOMEM without queuing reset work, so nothing ever clears the bit.
> This leaves the device permanently stuck in the restarting state,
> causing all subsequent reset attempts to be silently skipped.
>
> Fix this by using test_and_set_bit() to atomically claim the
> RESTARTING state, preventing duplicate reset scheduling races under
> concurrent fatal error reporting. If the subsequent allocation fails,
> clear the bit to restore clean state so future reset attempts can
> proceed.
>
> Cc: stable@vger.kernel.org
> Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework")
> Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
> Co-developed-by: Maksim Lukoshkov <maksim.lukoshkov@intel.com>
> Signed-off-by: Maksim Lukoshkov <maksim.lukoshkov@intel.com>
> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> ---
> drivers/crypto/intel/qat/qat_common/adf_aer.c | 7 ++++---
> 1 file changed, 4 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] crypto: qat - protect service table iterations with service_lock
From: Herbert Xu @ 2026-05-29 6:06 UTC (permalink / raw)
To: Ahsan Atta
Cc: linux-crypto, qat-linux, stable, Maksim Lukoshkov,
Giovanni Cabiddu
In-Reply-To: <20260520124155.211119-1-ahsan.atta@intel.com>
On Wed, May 20, 2026 at 01:41:55PM +0100, Ahsan Atta wrote:
> The service_table list is protected by service_lock when entries are
> added or removed (in adf_service_add() and adf_service_remove()), but
> several functions iterate over the list without holding this lock.
>
> A concurrent adf_service_register() or adf_service_unregister() call
> could modify the list during traversal, leading to list corruption or
> a use-after-free.
>
> Fix this by holding service_lock across all list_for_each_entry()
> iterations of service_table in adf_dev_init(), adf_dev_start(),
> adf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(),
> adf_dev_restarted_notify(), and adf_error_notifier().
>
> The lock ordering is safe: callers of the static helpers (adf_dev_up()
> and adf_dev_down()) acquire state_lock before service_lock, and no
> event_hld callback or service_lock holder ever acquires state_lock in
> the reverse order.
>
> Cc: stable@vger.kernel.org
> Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework")
> Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
> Co-developed-by: Maksim Lukoshkov <maksim.lukoshkov@intel.com>
> Signed-off-by: Maksim Lukoshkov <maksim.lukoshkov@intel.com>
> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> ---
> drivers/crypto/intel/qat/qat_common/adf_init.c | 16 ++++++++++++++++
> 1 file changed, 16 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: qat - use pci logging variants for PCI-specific messages
From: Herbert Xu @ 2026-05-29 6:07 UTC (permalink / raw)
To: Ahsan Atta; +Cc: linux-crypto, qat-linux, Andy Shevchenko, Giovanni Cabiddu
In-Reply-To: <20260520125150.211802-1-ahsan.atta@intel.com>
On Wed, May 20, 2026 at 01:51:50PM +0100, Ahsan Atta wrote:
> Replace dev_err(&pdev->dev, ...), dev_info(&pdev->dev, ...) and
> dev_dbg(&pdev->dev, ...) with pci_err(), pci_info() and pci_dbg()
> where the log message relates to a PCI subsystem operation such as
> device enable, BAR mapping, PCI region requests, PCI state
> save/restore, and SR-IOV management.
>
> Messages about driver-level logic (NUMA topology, device matching,
> accelerator units, capabilities, configuration, DMA) are intentionally
> left as dev_err() even when a struct pci_dev pointer is in scope,
> since those concern the device or driver rather than the PCI bus.
>
> No functional change.
>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> ---
> drivers/crypto/intel/qat/qat_420xx/adf_drv.c | 8 +++----
> drivers/crypto/intel/qat/qat_4xxx/adf_drv.c | 8 +++----
> drivers/crypto/intel/qat/qat_c3xxx/adf_drv.c | 4 ++--
> .../crypto/intel/qat/qat_c3xxxvf/adf_drv.c | 2 +-
> drivers/crypto/intel/qat/qat_c62x/adf_drv.c | 4 ++--
> drivers/crypto/intel/qat/qat_c62xvf/adf_drv.c | 2 +-
> drivers/crypto/intel/qat/qat_common/adf_aer.c | 21 +++++++++----------
> .../crypto/intel/qat/qat_common/adf_sriov.c | 2 +-
> .../crypto/intel/qat/qat_dh895xcc/adf_drv.c | 4 ++--
> .../crypto/intel/qat/qat_dh895xccvf/adf_drv.c | 2 +-
> 10 files changed, 28 insertions(+), 29 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 kernel] crypto/ccp/tsm: Enable the root port after the endpoint
From: Herbert Xu @ 2026-05-29 6:07 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: linux-crypto, linux-kernel, Tom Lendacky, David S. Miller,
Dan Williams, x86, linux-coco, Pratik R . Sampat, Xu Yilun,
Aneesh Kumar K . V
In-Reply-To: <20260521074301.2369293-1-aik@amd.com>
On Thu, May 21, 2026 at 05:43:01PM +1000, Alexey Kardashevskiy wrote:
> The PCIe r7.0, chapter "6.33.8 Other IDE Rules" mandates if selective IDE
> is enabled for config requersts, a stream must be enabled on the endpoint
> before enabling it on the rootport:
>
> ===
> For Selective IDE, the Stream must not be used until it has been enabled in
> both Partner Ports. For cases where one of the Partner Ports is a Root Port
> and Selective IDE for Configuration Requests is enabled, the other
> Partner Port must be enabled prior to the Root Port. For other scenarios,
> the mechanisms to satisfy this requirement are implementation-specific.
> ===
>
> Do what the spec says.
>
> Fixes: 4be423572da1 ("crypto/ccp: Implement SEV-TIO PCIe IDE (phase1)")
> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
> ---
> drivers/crypto/ccp/sev-dev-tsm.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 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: loongson - Select CRYPTO_RNG
From: Herbert Xu @ 2026-05-29 6:08 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-kernel, loongarch, Huacai Chen, Qunqin Zhao,
Yinggang Gu, Lee Jones, kernel test robot, stable
In-Reply-To: <20260522022525.12976-1-ebiggers@kernel.org>
On Thu, May 21, 2026 at 09:25:25PM -0500, Eric Biggers wrote:
> This driver registers a rng_alg, so it requires CRYPTO_RNG.
>
> Fixes: 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202605201622.qWOiiZTV-lkp@intel.com/
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> drivers/crypto/loongson/Kconfig | 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 0/3] AF_ALG: Remove support for AIO and old-style drivers
From: Herbert Xu @ 2026-05-29 6:09 UTC (permalink / raw)
To: demiobenour
Cc: David S. Miller, Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni,
Willem de Bruijn, Jens Axboe, Jakub Kicinski, Simon Horman,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Jonathan Corbet,
Shuah Khan, Eric Biggers, Ard Biesheuvel, linux-crypto,
linux-kernel, io-uring, netdev, linux-perf-users, linux-doc
In-Reply-To: <20260523-af-alg-harden-v1-0-c76755c3a5c5@gmail.com>
On Sat, May 23, 2026 at 03:43:01PM -0400, Demi Marie Obenour via B4 Relay wrote:
> AF_ALG is a deprecated API only useful for compatibility with existing
> userspace. It has had a lot of vulnerabilities, including the infamous
> CopyFail.
>
> Rip out support for offload drivers, which tend to be buggy. Also rip
> out support for AIO, which actually bloats the entire socket subsystem.
>
> Only compile-tested.
>
> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
> ---
> Demi Marie Obenour (3):
> net: Remove support for AIO on sockets
> AF_ALG: Drop support for off-CPU cryptography
> AF_ALG: Document that it is *always* slower
>
> Documentation/crypto/userspace-if.rst | 26 ++++++++--
> crypto/af_alg.c | 35 ++------------
> crypto/algif_aead.c | 43 ++++-------------
> crypto/algif_hash.c | 4 +-
> crypto/algif_rng.c | 4 +-
> crypto/algif_skcipher.c | 66 ++++++--------------------
> include/crypto/if_alg.h | 19 ++++++--
> include/linux/socket.h | 1 -
> io_uring/net.c | 1 -
> net/compat.c | 1 -
> net/socket.c | 7 +--
> tools/perf/trace/beauty/include/linux/socket.h | 1 -
> 12 files changed, 70 insertions(+), 138 deletions(-)
> ---
> base-commit: 49e05bb00f2e8168695f7af4d694c39e1423e8a2
> change-id: 20260502-af-alg-harden-900849451653
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] crypto: sun4i-ss: restrict PRNG seed length to prevent heap overflow
From: Herbert Xu @ 2026-05-29 6:11 UTC (permalink / raw)
To: Tianchu Chen
Cc: clabbe.montjoie, davem, wens, jernej.skrabec, samuel,
linux-crypto, linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <af749a8447bd7f0e9dd26ca6c87e9c6afecb09d9@linux.dev>
On Thu, May 28, 2026 at 02:53:17PM +0000, Tianchu Chen wrote:
>
> diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
> index 491fcb7b8..010fa891c 100644
> --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
> +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
> @@ -8,6 +8,8 @@ int sun4i_ss_prng_seed(struct crypto_rng *tfm, const u8 *seed,
> struct rng_alg *alg = crypto_rng_alg(tfm);
>
> algt = container_of(alg, struct sun4i_ss_alg_template, alg.rng);
> + if (slen > sizeof(algt->ss->seed))
> + return -EINVAL;
This should simply ignore the extra data instead of failing.
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