kernel/linux.git/drivers/s390/crypto, branch v6.12.80

s390/zcrypt: Enable AUTOSEL_DOM for CCA serialnr sysfs attribute

2026-03-25T10:08:48+00:00

[ Upstream commit 598bbefa8032cc58b564a81d1ad68bd815c8dc0f ] The serialnr sysfs attribute for CCA cards when queried always used the default domain for sending the request down to the card. If for any reason exactly this default domain is disabled then the attribute code fails to retrieve the CCA info and the sysfs entry shows an empty string. Works as designed but the serial number is a card attribute and thus it does not matter which domain is used for the query. So if there are other domains on this card available, these could be used. So extend the code to use AUTOSEL_DOM for the domain value to address any online domain within the card for querying the cca info and thus show the serialnr as long as there is one domain usable regardless of the default domain setting. Fixes: 8f291ebf3270 ("s390/zcrypt: enable card/domain autoselect on ep11 cprbs") Suggested-by: Ingo Franzki Signed-off-by: Harald Freudenberger Reviewed-by: Ingo Franzki Cc: stable@vger.kernel.org Signed-off-by: Vasily Gorbik [ preserved zc->online as the fourth argument to cca_get_info() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

s390/ap: Fix wrong APQN fill calculation

2026-01-30T09:28:46+00:00

commit 3317785a8803db629efc759d811d0f589d3a0b2d upstream. The upper limit of the firmware queue fill state for each APQN is reported by the hwinfo.qd field. This field shows the numbers 0-7 for 1-8 queue spaces available. But the exploiting code assumed the real boundary is stored there and thus stoppes queuing in messages one tick too early. Correct the limit calculation and thus offer a boost of 12.5% performance for high traffic on one APQN. Fixes: d4c53ae8e4948 ("s390/ap: store TAPQ hwinfo in struct ap_card") Cc: stable@vger.kernel.org Reported-by: Ingo Franzki Reviewed-by: Ingo Franzki Signed-off-by: Harald Freudenberger Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

s390/ap: Don't leak debug feature files if AP instructions are not available

2025-12-18T12:54:47+00:00

[ Upstream commit 020d5dc57874e58d3ebae398f3fe258f029e3d06 ] If no AP instructions are available the AP bus module leaks registered debug feature files. Change function call order to fix this. Fixes: cccd85bfb7bf ("s390/zcrypt: Rework debug feature invocations.") Reviewed-by: Harald Freudenberger Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin

s390/ap: Unmask SLCF bit in card and queue ap functions sysfs

2025-08-15T10:14:05+00:00

[ Upstream commit 123b7c7c2ba725daf3bfa5ce421d65b92cb5c075 ] The SLCF bit ("stateless command filtering") introduced with CEX8 cards was because of the function mask's default value suppressed when user space read the ap function for an AP card or queue. Unmask this bit so that user space applications like lszcrypt can evaluate and list this feature. Fixes: d4c53ae8e494 ("s390/ap: store TAPQ hwinfo in struct ap_card") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

s390/pkey: Prevent overflow in size calculation for memdup_user()

2025-07-06T09:01:38+00:00

commit 7360ee47599af91a1d5f4e74d635d9408a54e489 upstream. Number of apqn target list entries contained in 'nr_apqns' variable is determined by userspace via an ioctl call so the result of the product in calculation of size passed to memdup_user() may overflow. In this case the actual size of the allocated area and the value describing it won't be in sync leading to various types of unpredictable behaviour later. Use a proper memdup_array_user() helper which returns an error if an overflow is detected. Note that it is different from when nr_apqns is initially zero - that case is considered valid and should be handled in subsequent pkey_handler implementations. Found by Linux Verification Center (linuxtesting.org). Fixes: f2bbc96e7cfa ("s390/pkey: add CCA AES cipher key support") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Reviewed-by: Holger Dengler Reviewed-by: Heiko Carstens Link: https://lore.kernel.org/r/20250611192011.206057-1-pchelkin@ispras.ru Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman

s390/vfio-ap: Fix no AP queue sharing allowed message written to kernel log

2025-05-29T09:02:02+00:00

[ Upstream commit d33d729afcc8ad2148d99f9bc499b33fd0c0d73b ] An erroneous message is written to the kernel log when either of the following actions are taken by a user: 1. Assign an adapter or domain to a vfio_ap mediated device via its sysfs assign_adapter or assign_domain attributes that would result in one or more AP queues being assigned that are already assigned to a different mediated device. Sharing of queues between mdevs is not allowed. 2. Reserve an adapter or domain for the host device driver via the AP bus driver's sysfs apmask or aqmask attribute that would result in providing host access to an AP queue that is in use by a vfio_ap mediated device. Reserving a queue for a host driver that is in use by an mdev is not allowed. In both cases, the assignment will return an error; however, a message like the following is written to the kernel log: vfio_ap_mdev e1839397-51a0-4e3c-91e0-c3b9c3d3047d: Userspace may not re-assign queue 00.0028 already assigned to \ e1839397-51a0-4e3c-91e0-c3b9c3d3047d Notice the mdev reporting the error is the same as the mdev identified in the message as the one to which the queue is being assigned. It is perfectly okay to assign a queue to an mdev to which it is already assigned; the assignment is simply ignored by the vfio_ap device driver. This patch logs more descriptive and accurate messages for both 1 and 2 above to the kernel log: Example for 1: vfio_ap_mdev 0fe903a0-a323-44db-9daf-134c68627d61: Userspace may not assign queue 00.0033 to mdev: already assigned to \ 62177883-f1bb-47f0-914d-32a22e3a8804 Example for 2: vfio_ap_mdev 62177883-f1bb-47f0-914d-32a22e3a8804: Can not reserve queue 00.0033 for host driver: in use by mdev Signed-off-by: Anthony Krowiak Link: https://lore.kernel.org/r/20250311103304.1539188-1-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin

s390/pkey_pckmo: Return with success for valid protected key types

2024-10-16T09:32:32+00:00

The key_to_protkey handler function in module pkey_pckmo should return with success on all known protected key types, including the new types introduced by fd197556eef5 ("s390/pkey: Add AES xts and HMAC clear key token support"). Fixes: fd197556eef5 ("s390/pkey: Add AES xts and HMAC clear key token support") Signed-off-by: Holger Dengler Reviewed-by: Ingo Franzki Signed-off-by: Heiko Carstens

s390/ap: Fix CCA crypto card behavior within protected execution environment

2024-10-10T13:31:55+00:00

A crypto card comes in 3 flavors: accelerator, CCA co-processor or EP11 co-processor. Within a protected execution environment only the accelerator and EP11 co-processor is supported. However, it is possible to set up a KVM guest with a CCA card and run it as a protected execution guest. There is nothing at the host side which prevents this. Within such a guest, a CCA card is shown as "illicit" and you can't do anything with such a crypto card. Regardless of the unsupported CCA card within a protected execution guest there are a couple of user space applications which unconditional try to run crypto requests to the zcrypt device driver. There was a bug within the AP bus code which allowed such a request to be forwarded to a CCA card where it is finally rejected and the driver reacts with -ENODEV but also triggers an AP bus scan. Together with a retry loop this caused some kind of "hang" of the KVM guest. On startup it caused timeouts and finally led the KVM guest startup fail. Fix that by closing the gap and make sure a CCA card is not usable within a protected execution environment. Another behavior within an protected execution environment with CCA cards was that the se_bind and se_associate AP queue sysfs attributes where shown. The implementation unconditional always added these attributes. Fix that by checking if the card mode is supported within a protected execution environment and only if valid, add the attribute group. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens

Merge tag 's390-6.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

2024-09-28T16:11:46+00:00

Pull more s390 updates from Vasily Gorbik: - Clean up and improve vdso code: use SYM_* macros for function and data annotations, add CFI annotations to fix GDB unwinding, optimize the chacha20 implementation - Add vfio-ap driver feature advertisement for use by libvirt and mdevctl * tag 's390-6.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/vfio-ap: Driver feature advertisement s390/vdso: Use one large alternative instead of an alternative branch s390/vdso: Use SYM_DATA_START_LOCAL()/SYM_DATA_END() for data objects tools: Add additional SYM_*() stubs to linkage.h s390/vdso: Use macros for annotation of asm functions s390/vdso: Add CFI annotations to __arch_chacha20_blocks_nostack() s390/vdso: Fix comment within __arch_chacha20_blocks_nostack() s390/vdso: Get rid of permutation constants

[tree-wide] finally take no_llseek out

2024-09-27T15:18:43+00:00

no_llseek had been defined to NULL two years ago, in commit 868941b14441 ("fs: remove no_llseek") To quote that commit, At -rc1 we'll need do a mechanical removal of no_llseek - git grep -l -w no_llseek | grep -v porting.rst | while read i; do sed -i '/\/d' $i done would do it. Unfortunately, that hadn't been done. Linus, could you do that now, so that we could finally put that thing to rest? All instances are of the form .llseek = no_llseek, so it's obviously safe. Signed-off-by: Al Viro Signed-off-by: Linus Torvalds