Pull x86 SEV updates from Borislav Petkov:
- Report in sysfs which SEV confidential computing features are enabled
in the environment so that related components like a SVSM can query
them and do appropriate configuration
- Add support for a new AMD SEV instruction called RMPOPT which can be
used to reduce the performance overhead of doing confidential guests'
page ownership verification and the like. Work by Ashish Kalra
* tag 'x86_sev_for_v7.4_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/sev: Report MSR_AMD64_SEV in sysfs
x86/sev: Do RMP optimizations on SNP guest shutdown
x86/sev: Perform RMP optimizations asynchronously
x86/sev: Initialize RMPOPT configuration MSRs
x86/sev: Disable CPU hotplug while SNP is active
x86/cpufeatures: Add X86_FEATURE_RMPOPT feature flag
Release the DMA channel directly and consolidate the error paths.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Use the existing fast variable instead of testing for TDES_FLAGS_FAST in
dd->flags again.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Use two separate input and output scatterlists instead of an array.
Also use DMA_SLAVE_BUSWIDTH_4_BYTES directly and drop the now-unused
addr_width variable.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
adf_dev_stop_async() sends the RESTARTING_COMPLETE message after
adf_dev_down() has returned, but adf_dev_down() already destroyed the
lock that message takes.
Both run in sequence in the same worker, so every PF restart locks a
destroyed mutex. With CONFIG_DEBUG_MUTEXES on a dh895xcc with 32 host-bound
VFs this trips on the first PF reset:
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0
Workqueue: adf_vf_stop_wq adf_dev_stop_async [intel_qat]
Call Trace:
adf_gen2_pfvf_send+0x210/0x530 [intel_qat]
adf_vf2pf_notify_restart_complete+0x55/0x80 [intel_qat]
adf_dev_stop_async+0xdb/0x140 [intel_qat]
The notification cannot move before adf_dev_down(): the PF waits for it
before its own reset and the VF must tear down its rings first.
vf2pf_lock protects the VF2PF CSR and is unrelated to the PF2VF bottom half
it is initialised alongside. Tie its lifetime to the accel device, next to
state_lock in adf_devmgr_add_dev()/adf_devmgr_rm_dev(), so it stays valid
for messages sent outside the device up/down cycle. It is only touched for
VFs, which set is_vf before adf_devmgr_add_dev() and keep it set until
adf_devmgr_rm_dev().
Fixes: 6f1b523634 ("crypto: qat - fix recovery flow for VFs")
Cc: stable@vger.kernel.org
Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
state_lock is initialised at the end of adf_devmgr_add_dev(), but the VF
on host path whose id mapping already exists returns earlier via
'goto unlock'. That mapping outlives the VF, so this path is taken every
time a VF is recreated on a BDF that already hosted one, e.g.:
echo 0 > sriov_numvfs
echo 32 > sriov_numvfs
accel_dev is freshly allocated on each probe, so state_lock is left zeroed
and adf_dev_up() takes an uninitialised mutex. With CONFIG_DEBUG_MUTEXES
this is reported on a dh895xcc with 32 host-bound VFs:
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0
Call Trace:
adf_dev_up+0x27/0xe0 [intel_qat]
adf_probe+0x700/0xa80 [qat_dh895xccvf]
local_pci_probe+0xd5/0x190
The same happens on teardown when adf_dev_down() locks it again.
Initialise the lock next to the other per-device state, before the tables
are updated, so it is done on every path.
Fixes: 1bdc85550a ("crypto: qat - fix concurrency issue when device state changes")
Cc: stable@vger.kernel.org
Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The talitos interrupt handlers schedule priv->done_task[] via
tasklet_schedule(). Since the second IRQ support, probe has requested
the IRQs before calling tasklet_init(), so an interrupt already pending
when a line is requested, e.g. engine state left by the bootloader or
a kexec'd kernel, would schedule a tasklet with a NULL callback.
Look up the IRQ numbers and map the registers up front, so that
-EPROBE_DEFER returns before anything is allocated and the done_task[]
selection and reset_device() can see the secondary IRQ. Only request
the IRQs once the channel fifos are allocated and init_device() has
reset the engine. This matches remove(), which frees the IRQs before
killing the tasklets.
remove() frees every IRQ number that is > 0, so make sure that only
requested lines are set when it runs from the probe error path: clear
both numbers when probe fails before the request, and clear any line
talitos_probe_irq() did not request. Previously a failed primary
request in the two-IRQ case freed the never-requested secondary line.
Fixes: c3e337f88a ("crypto: talitos - support for channel remap and 2nd IRQ")
Assisted-by: LLM
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Remove the shash, authkey, and auth fields from sa_tfm_ctx since they
have no purpose and create confusion with fields that actually matter.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The get_num_accels() hook in struct adf_hw_device_data has had no
callers since commit d237230728 ("crypto: qat - remove unused
character device and IOCTLs"), which deleted its last user in
adf_ctl_drv.c. Every device driver still populates it and two
implementations are still exported, all of it dead code.
Remove the hook, its generation-level implementations
adf_gen2_get_num_accels() and adf_gen4_get_num_accels(), the
per-device static implementations and all the assignments.
The hw_data->num_accel field is left untouched as it is still used.
Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
VF2PF interrupts are edge-triggered: a source only fires on a
masked -> unmasked transition of VM2PF_MSK, not by being unmasked.
adf_enable_all_vf2pf_interrupts() does a plain read-modify-write
unmask, assuming VM2PF_MSK still holds the all-masked value left by
adf_disable_all_vf2pf_interrupts().
That breaks across a device reset: adf_dev_autoreset() (and AER
recovery) FLR the PF while VFs stay alive, so a VF can latch a source
in VM2PF_SOU with no vectors set up to deliver it. The FLR then resets
VM2PF_MSK to its power-on default of 0 (unmasked) without a software
write, so the following RMW unmask writes 0 over an already-0
register: no edge occurs and the latched VF2PF message is never
delivered.
Fix by having adf_enable_all_vf2pf_interrupts() mask all sources
immediately before unmasking them, mirroring the idiom already used in
adf_gen4_disable_pending_vf2pf_interrupts(), forcing the required edge
regardless of the prior state of VM2PF_MSK.
Fixes: 5751850005 ("crypto: qat - keep VFs enabled during reset")
Signed-off-by: George Abraham P <george.abraham.p@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Since the commit 66b9a095f7
("crypto: caam - Add support of paes algorithm")
The shared descriptor then loads a zero-length key and the SEC decodes
the inlined key bytes as commands.
Test: with CONFIG_CRYPTO_SELFTESTS on LX2160A every skcipher but xts fails:
dpaa2_caam dpseci.0: 40000307: DECO: desc idx 3: Invalid LOAD Command
alg: skcipher: ctr-aes-caam-qi2 encryption failed on test vector 0; expected_error=0, actual_error=-22, cfg="in-place (one sglist)"
caamalg_qi.c is compile-tested only.
Fixes: 66b9a095f7 ("crypto: caam - Add support of paes algorithm")
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Since the commit
060ce5037d ("crypto: caam/qi2 - add support for dpseci_reset()")
probe resets every DPSECI.
On a DPSECI the MC has just created from the DPL, never enabled,
MC 10.40.x then logs for each of its queues:
[E, qbman_rec_isr:396, QBMAN] QBMAN recoverable event 0x1000000
[E, dpmng_dump_rerr_fqid:1335, QBMAN] REL_FQ (FQ[0]) has 1 messages, dumping up to 16:
[W, DPSECI] DPSECI ID[0]: Flush on queue 43 not confirmed
That is 16 error lines for an 8-queue DPSECI, at every boot, although
there is nothing to flush: a disabled DPSECI has no request in flight.
The reset at remove is unchanged.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The decompress() function subtracts the header-supplied `ignore` value
(a u16 from the compressed stream) from `dlen` (the number of bytes
produced by the decompressor) without checking that ignore <= dlen.
If a caller decompresses a crafted buffer where `hdr->ignore` exceeds
the actual decompressed length, the subtraction wraps around to a
near-UINT_MAX value. The subsequent memcpy() then copies gigabytes of
data past the destination buffer, causing an out-of-bounds kernel write.
Add a bounds check before the subtraction and return -EINVAL if the
value is inconsistent.
Cc: stable@vger.kernel.org
Signed-off-by: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
caam_rsa_set_priv_key_form() frees the partially allocated key
components (p, q, tmp1, tmp2, dp, dq) with kfree_sensitive() on its
error path, but does not set those pointers to NULL afterward.
When the function returns an error, caam_rsa_set_priv_key() jumps to
its err label and calls caam_rsa_free_key(), which frees all of those
same pointers again, resulting in a double-free.
This is reachable when the allocation of q, tmp1, tmp2, dp, dq or qinv
fails, e.g. under memory pressure, or for a malformed key whose CRT
members decode to zero length and make caam_read_rsa_crt() return NULL.
Set each pointer to NULL right after freeing it so that the subsequent
caam_rsa_free_key() call becomes a no-op for the already-freed fields.
Fixes: 52e26d77b8 ("crypto: caam - add support for RSA key form 2")
Cc: stable@vger.kernel.org
Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
Reviewed-by: Sahil Malhotra <sahil.malhotra@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Annotate the 'qm_cap_table' and 'dev_cap_table' pointer fields in
'struct hisi_qm_cap_tables' with the '__counted_by_ptr' attribute.
This improves bounds checking via CONFIG_UBSAN_BOUNDS and
CONFIG_FORTIFY_SOURCE, allowing KASAN and compiler diagnostics to
detect out-of-bounds accesses.
The 'qm_cap_table' pointer is associated with 'qm_cap_size' which
specifies its element count. Similarly, 'dev_cap_table' is associated
with 'dev_cap_size'.
To ensure safety under compiler instrumentation, the assignments in the
initialization paths have been updated to set the 'size'/'count' fields
prior to setting the pointer fields. This prevents any transient state
where the pointer is valid but the count is 0 (or uninitialized),
ensuring that subsequent accesses to these tables do not trigger
false-positive bounds check panics.
Cc: codemender-patching+linux@google.com
Assisted-by: LLM
Signed-off-by: Bill Wendling <morbo@google.com>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Longfang Liu <liulongfang@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
sa_prepare_iopads() has multiple bugs, as discussed at
https://lore.kernel.org/linux-crypto/20260831055141.1632832-1-s-vadapalli@ti.com/T/#u
- Commit 3bf5337879 ("crypto: sha256 - Use the partial block API")
introduced a 1-byte buffer overflow in the SHA-256 case by making the
crypto_shash_export() write 1 more than sizeof(struct sha256_state).
- It never worked for HMAC keys longer than 64 bytes in the first place.
Fix both of these bugs by just using the crypto library to prepare the
key, like what the chelsio and qat drivers do. Also remove the
pointless use of an indirect call.
Fixes: 3bf5337879 ("crypto: sha256 - Use the partial block API")
Fixes: d2c8ac187f ("crypto: sa2ul - Add AEAD algorithm support")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Authenc permits a nonempty associated-data string with no plaintext. The
Atmel driver accepts such a request, has SHA process the associated data,
and then unconditionally asks AES DMA to transfer zero bytes. The Atmel
DMA engines reject the zero-length descriptor, so the valid request fails,
normally with -ENOMEM.
Skip the AES transfer when textlen is zero and proceed directly to SHA
finalization.
Once an HMAC transform has cached its inner and outer states, SHA can
complete this path synchronously. The forced ahash completion callback
then invokes the AES finalizer through a void function and discards its
return value. This loses -EBADMSG for a mismatched tag and reports
successful decryption.
For synchronous SHA completion, release the SHA device without invoking
the ahash callback and call the AES finalizer directly. Its result then
propagates through the synchronous call chain. Keep the existing callback
path for asynchronous completion.
On a SAM9X75, the unpatched driver failed valid AAD-only requests and
returned success for a bad tag after the transform had been used once. With
this change, bad tags return -EBADMSG for both fresh and reused transforms.
Fixes: 89a82ef87e ("crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Replace the open-coded pm_runtime_get_sync() + pm_runtime_put_noidle()
error handling pattern with pm_runtime_resume_and_get(), which already
does this internally.
No functional change.
Found by manual code inspection.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Replace the open-coded pm_runtime_get_sync() + pm_runtime_put_noidle()
error handling pattern with pm_runtime_resume_and_get(), which already
does this internally.
No functional change.
Found by manual code inspection.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Replace the open-coded pm_runtime_get_sync() + pm_runtime_put_noidle()
error handling pattern with pm_runtime_resume_and_get(), which already
does this internally.
No functional change.
Found by manual code inspection.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Use memcpy_and_pad() instead of separate memcpy() and memset() calls to
simplify aead_hmac_init().
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Use memcpy_and_pad() instead of separate memcpy() and memset() calls to
simplify aead_hmac_init().
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Use memcpy_and_pad() instead of separate memcpy() and memset() calls to
simplify register_chain_var().
Signed-off-by: Thorsten Blum <blum@kernel.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
On PCI devices using MSI-X, ccp5_irq_handler() schedules irq_tasklet.
The teardown paths release the IRQ but do not drain a tasklet that was
already queued, so it can access ccp after the device-managed allocation
has been released.
Kill the tasklet after releasing the IRQ in both the initialization
error path and ccp5_destroy().
Fixes: 6263b51eb3 ("crypto: ccp - Change ISR handler method for a v5 CCP")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
On PCI devices using MSI-X, ccp_irq_handler() schedules irq_tasklet. The
teardown paths release the IRQ but do not drain a tasklet that was
already queued, so it can access ccp after the device-managed allocation
has been released.
Kill the tasklet after releasing the IRQ in both the initialization
error path and ccp_destroy().
Fixes: 7b537b24e7 ("crypto: ccp - Change ISR handler method for a v3 CCP")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
sfs_ioctl() reads psp_master->sfs_data and caches it in sfs_dev before
taking sfs_ioctl_mutex, while sfs_dev_destroy() frees sfs_dev->page
and sfs_dev->command_buf with no locking at all and only clears
psp->sfs_data afterwards. A call to sfs_ioctl() that reads sfs_data
just before sfs_dev_destroy() runs will still acquire the mutex and
go on to use the now-freed command buffer in send_sfs_cmd().
Have both functions take sfs_ioctl_mutex before touching
psp->sfs_data, so a call that is already using sfs_dev completes
before teardown can free it, and a call arriving after teardown sees
sfs_data cleared and returns -ENODEV instead of racing it.
Fixes: 648dbccc03 ("crypto: ccp - Add AMD Seamless Firmware Servicing (SFS) driver")
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Reviewed-by: Ashish Kalra <ashish.kalra@amd.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The QAT VF migration state buffer is allocated with kmalloc(), while
qat_vf_save_state() exposes all state_size bytes to userspace. The state
manager writes only the serialized sections, leaving the unused tail
unchanged. The first save can therefore disclose stale heap contents,
and subsequent saves can disclose data left by an earlier migration.
Zero the whole buffer before writing the setup data. Once the setup data
is present, preserve it and zero the remaining state area before each
state save.
Fixes: f0bbfc391a ("crypto: qat - implement interface for live migration")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
adf_cfg_add_key_value_param() now resolves the target section under
cfg->lock, but still calls adf_cfg_key_val_get(), which re-walks the
section list to find that same section and then walks param_head to
read the current value into a temporary buffer. If the value differs it
calls adf_cfg_keyval_remove(), which walks param_head a third time to
locate the entry that was already found.
Look up the existing entry once with adf_cfg_key_value_find() and act on
that pointer directly: free the new copy if the value is unchanged, or
unlink and free the old entry before adding the new one. This drops two
redundant list walks and the on-stack temp_val copy, and removes the now
unused adf_cfg_keyval_remove() helper. No functional change.
Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
adf_cfg_sec_find() walks the per-device section list without holding
cfg->lock, and the returned section pointer is used later under the
lock. A concurrent section deletion under cfg->lock
(adf_cfg_del_all_except() on device down, or adf_cfg_dev_remove() on
removal) can free the section first, leading to a use-after-free.
The debugfs dev_cfg reader has the same problem: qat_dev_cfg_show()
walks both the section list and each section's param_head under the
global qat_cfg_read_lock mutex, not the per-device cfg->lock used by the
add and delete paths, so the two do not serialise. Updating an existing
key frees the old key_val under cfg->lock, so even a config write
concurrent with an open dev_cfg read can free an entry mid-walk, a wider
window than section deletion alone.
Take cfg->lock around the section lookup in adf_cfg_add_key_value_param()
and around the lookup and insert in adf_cfg_section_add(), and use
down_read()/up_read(&cfg->lock) in the debugfs start/stop callbacks.
Remove the now-unused qat_cfg_read_lock.
While here, return -ENOENT rather than -EFAULT when the section is not
found; EFAULT (bad userspace address) is not meaningful for this case.
Fixes: d8cba25d2c ("crypto: qat - Intel(R) QAT driver framework")
Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Several macros, the hpre_asym_request::err field and the hpre::status
field are defined but never referenced. Remove them.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Seven functions in hpre_main.c open-code the same cluster number
extraction from HPRE_CORE_INFO. Extract into hpre_get_clusters_num().
hpre_pre_store_cap_reg() uses a local hpre_cap[] array rather than
qm->cap_tables.dev_cap_table[] and is therefore not converted.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The HPRE driver hard-codes GFP_ATOMIC for RSA/DH and GFP_KERNEL for
ECDH. This may cause "scheduling while atomic" in atomic context or
unnecessary allocation failures under memory pressure.
Select GFP flags dynamically based on CRYPTO_TFM_REQ_MAY_SLEEP and
store them in hpre_asym_request::flags. The areq field is a union of
rsa/dh/ecdh request pointers; reading base.flags through any union
member other than the one that was written would be type-punning, so
a dedicated flags field avoids that.
Fixes: 98dfa9343f ("crypto: hisilicon/hpre - don't use GFP_KERNEL to alloc mem during softirq")
Cc: stable@vger.kernel.org
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
hpre_ecdh_dst_data_init() rejects valid requests whose output length
does not equal ctx->key_sz << 1, and maps the user buffer using the
user-provided len instead of the hardware transfer size. Drop the
redundant length check and use ctx->key_sz << 1 for dma_map_single()
so the whole hardware output is mapped.
Fixes: 05e7b906aa ("crypto: hisilicon/hpre - add 'ECDH' algorithm")
Cc: stable@vger.kernel.org
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
hpre_ecdh_msg_request_set() returns -EINVAL when the output buffer
is too small, after setting req->dst_len to the required size.
-EINVAL is misleading because the caller can retry with a larger
buffer. Return -EOVERFLOW as other kpp implementations do.
Fixes: 05e7b906aa ("crypto: hisilicon/hpre - add 'ECDH' algorithm")
Cc: stable@vger.kernel.org
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In hpre_ecdh_hw_data_clr_all(), req->dst is always NULL because
hpre_ecdh_dst_data_init() sets hpre_req->dst = NULL before mapping
the user buffer with dma_map_single(). The dma_free_coherent() call
on req->dst is therefore dead code. Remove it.
Fixes: 05e7b906aa ("crypto: hisilicon/hpre - add 'ECDH' algorithm")
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In hpre_rsa_drop_leading_zeros(), the loop condition dereferences *ptr
before checking *len, causing an out-of-bounds read when *len is zero.
Swap to while (*len && !**ptr) to test length first.
Fixes: c8b4b47707 ("crypto: hisilicon - add HiSilicon HPRE accelerator")
Cc: stable@vger.kernel.org
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In meson_irq_handler(), when an interrupt matches a flow but the status
register is empty, the driver prints an error but doesn't return. It
falls through the loop and incorrectly prints an `unknown irq` message.
Fix this by returning immediately. For empty status registers, return
IRQ_NONE instead of IRQ_HANDLED to avoid masking spurious interrupts and
allow the kernel to detect interrupt storms. Also use
dev_err_ratelimited() to prevent console lockups during an interrupt
storm.
Additionally, the handler returned IRQ_HANDLED for genuinely unknown
interrupts. Return IRQ_NONE instead for unhandled interrupts.
Cc: stable@vger.kernel.org
Fixes: 48fe583fe5 ("crypto: amlogic - Add crypto accelerator for amlogic GXL")
Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The driver currently gets the core clock and manually enables it using
clk_prepare_enable(). This requires matching calls to
clk_disable_unprepare() in the error paths and remove function.
Switch to devm_clk_get_enabled() instead. This lets the kernel handle
enabling and disabling the clock automatically, which allow us to drop
the manual cleanup code and keeps the probe function simple.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608310329.QgxCCMs1-lkp@intel.com/
Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
atmel_tdes_crypt_pdc() and atmel_tdes_crypt_dma() store the transfer
length in dd->dma_size and synchronize the bounce buffers before a slow
transfer.
Move the shared code to atmel_tdes_crypt_start() and use dd->dma_size in
atmel_tdes_crypt_pdc() and atmel_tdes_crypt_dma() instead of passing the
length separately.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
TI_CD_PAR_STS faults were being decoded under ERRSOU1, which is
incorrect for QAT GEN6 devices. They are actually raised on ERRSOU3.
Move the handling of TI_CD_PAR_STS faults as part of the ERRSOU3 logic
and split the status bits by their actual source:
- Bits 0-18 (TI_INT_ERR_DEVHALT) handled when a DEVHALT is signalled
and are counted once as ADF_RAS_FATAL.
- Bit 19 (TIMISCSTS) handled separately and counted as ADF_RAS_UNCORR.
Previously, a TI_INT_ERR_DEVHALT fault also incremented ADF_RAS_UNCORR
in addition to ADF_RAS_FATAL. Since a DEVHALT is already fatal, remove
the redundant increment.
Bits 20-25 of TI_CD_PAR_STS are unused/reserved on QAT GEN6. Remove them
from the mask.
Cc: stable@vger.kernel.org
Fixes: 7f3401d0a5 ("crypto: qat - enable RAS support for GEN6 devices")
Signed-off-by: Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Ahsan Atta <ahsan.atta@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
starfive_cryp_probe() publishes the crypto device after enabling its clocks
and deasserting its reset without checking whether those operations
succeeded.
Check each hardware activation step and unwind only the resources that were
actually enabled before returning the error.
Fixes: 42ef0e944b ("crypto: starfive - Add crypto engine support")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The new RMPOPT instruction helps manage per-CPU RMP optimization
structures inside the CPU. It takes a 1GB-aligned physical address and
either returns the status of the optimizations or tries to enable the
optimizations.
Initialize the per-CPU RMPOPT table base to the starting physical
address. This enables RMP optimization for up to 2 TB of system RAM on
all CPUs because this is the maximum the RMPOPT tables support.
The RMPOPT_BASE MSR can only be written after SNP is enabled, so the
enabling runs from the ccp SNP init path (and again on guest teardown)
rather than from an initcall. This is also in line with the intention to
not enable SNP by default but enable it on demand, when the ccp module
is loaded.
RMPOPT_BASE is programmed on all primary threads. RMPOPT_EN cannot be
cleared while SNP is enabled, and CPU hotplug is disabled while SNP is
active, so once programmed the MSRs stay set on all CPUs until SNP is
disabled. A set RMPOPT_EN on the local CPU therefore means the
programming has already been done and thus it can be skipped.
[ bp:
- Massage commit message
- move enabling logic into the commit message
- zap unnecessary comments
- cleanup ]
Suggested-by: Thomas Lendacky <thomas.lendacky@amd.com>
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://patch.msgid.link/7fdf0f5b1be4b561c884c5200d6606a947cbc09d.1789594774.git.ashish.kalra@amd.com
Pull crypto fix from Herbert Xu:
"Fix a regression in caam"
* tag 'v7.3-p4' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: caam - map job ring registers without claiming region
A transform may be initialized for the first time after the last
device has been removed from the driver list. Return -ENODEV when the
lookup is empty, before the debug message reads dd->dev.
Detected by static analysis and reviewed with AI-assisted source auditing.
Fixes: ebc82efa1c ("crypto: atmel - add Atmel SHA1/SHA256 driver")
Assisted-by: LLM
Signed-off-by: Slavin Liu <bolin.liu@seu.edu.cn>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
omap_sham_probe() allocates and starts a crypto engine, but the remove
path does not call the matching crypto_engine_exit(). The probe failure
path already performs this cleanup.
crypto_engine_alloc_init() creates a kthread worker for processing
requests. Without crypto_engine_exit() during driver removal, the
worker is left running after the device is removed.
Call crypto_engine_exit() after unregistering the algorithms and before
tearing down the remaining request handling resources. This stops the
engine and destroys its worker.
This issue was found by manual code inspection.
Fixes: 133c3d434d ("crypto: omap-sham - convert to use crypto engine")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
omap_des_probe() allocates and starts a crypto engine, but the remove
path does not call the matching crypto_engine_exit(). The probe failure
path already performs this cleanup.
crypto_engine_alloc_init() creates a kthread worker for processing
requests. Without crypto_engine_exit() during driver removal, the
worker is left running after the device is removed.
Call crypto_engine_exit() after unregistering the algorithms and before
tearing down the remaining request handling resources. This stops the
engine and destroys its worker.
This issue was found by manual code inspection.
Fixes: f1b77aaca8 ("crypto: omap-des - Integrate with the crypto engine framework")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
adf_dev_start() registered both alg sets in a single condition.
If qat_algs_register() succeeds but qat_asym_algs_register() fails,
ADF_STATUS_CRYPTO_ALGS_REGISTERED is left clear, so adf_dev_stop() skips
qat_algs_unregister(): the skciphers and aeads stay registered with
active_devs stuck at 1, pinning the module.
Both helpers leak active_devs internally as well - they increment it and
return without decrementing when a crypto_register_*() call fails, and
the asym path also leaves the already-registered akcipher behind.
Split the registration in adf_dev_start() so that an asym failure
unregisters qat_algs, and unwind active_devs (and the akcipher) on the
error paths of both register helpers. While at it, propagate the error
code returned by the register helpers instead of a blanket -EFAULT.
Fixes: 9b2f33a1bf ("crypto: qat - fix unregistration of crypto algorithms")
Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Linus Torvalds