pm24.git/drivers/s390/crypto, branch v6.5

s390/zcrypt: fix reply buffer calculations for CCA replies

2023-07-20T14:48:56Z

The length information for available buffer space for CCA replies is covered with two fields in the T6 header prepended on each CCA reply: fromcardlen1 and fromcardlen2. The sum of these both values must not exceed the AP bus limit for this card (24KB for CEX8, 12KB CEX7 and older) minus the always present headers. The current code adjusted the fromcardlen2 value in case of exceeding the AP bus limit when there was a non-zero value given from userspace. Some tests now showed that this was the wrong assumption. Instead the userspace value given for this field should always be trusted and if the sum of the two fields exceeds the AP bus limit for this card the first field fromcardlen1 should be adjusted instead. So now the calculation is done with this new insight in mind. Also some additional checks for overflow have been introduced and some comments to provide some documentation for future maintainers of this complicated calculation code. Furthermore the 128 bytes of fix overhead which is used in the current code is not correct. Investigations showed that for a reply always the same two header structs are prepended before a possible payload. So this is also fixed with this patch. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens

s390: fix various typos

2023-07-03T09:19:42Z

Fix various typos found with codespell. Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev

s390/zcrypt: remove ZCRYPT_MULTIDEVNODES kernel config option

2023-07-03T09:19:41Z

Remove ZCRYPT_MULTIDEVNODES kernel config option and make the dependent code always build. The last years showed, that this option is enabled on all distros and exploited by some features (for example CEX plugin for kubernetes). So remove this choice as it was never used to switch off the multiple devices support for the zcrypt device driver. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Alexander Gordeev

s390/zcrypt: do not retry administrative requests

2023-07-03T09:19:41Z

All kind of administrative requests should not been retried. Some card firmware detects this and assumes a replay attack. This patch checks on failure if the low level functions indicate a retry (EAGAIN) and checks for the ADMIN flag set on the request message. If this both are true, the response code for this message is changed to EIO to make sure the zcrypt API layer does not attempt to retry the request. As of now the ADMIN flag is set for a request message when - for EP11 the field 'flags' of the EP11 CPRB struct has the leftmost bit set. - for CCA when the CPRB minor version is 'T3', 'T5', 'T6' or 'T7'. Please note that the do-not-retry only applies to a request which has been sent to the card (= has been successfully enqueued) but the reply indicates some kind of failure and by default it would be replied. It is totally fine to retry a request if a previous attempt to enqueue the msg into the firmware queue had some kind of failure and thus the card has never seen this request. Reported-by: Frank Uhlig Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org Signed-off-by: Alexander Gordeev

s390/zcrypt: cleanup some debug code

2023-07-03T09:19:41Z

This patch removes most of the debug code which is build in when CONFIG_ZCRYPT_DEBUG is enabled. There is no real exploiter for this code any more and at least one ioctl fails with this code enabled. The CONFIG_ZCRYPT_DEBUG kernel config option still makes sense as some debug sysfs entries can get enabled with this and maybe long term a new better designed debug and error injection way will get introduced. This patch only removes code surrounded by the named kernel config option. This option should by default always be off anyway. The structs and defines removed by the patch have been used only by code surrounded by a CONFIG_ZCRYPT_DEBUG ifdef and thus can be removed also. In the end this patch removes all the failure-injection possibilities which had been available when the kernel had been build with CONFIG_ZCRYPT_DEBUG. It has never been used that much and was too unflexible anyway. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Alexander Gordeev

s390/zcrypt: use kvmalloc_array() instead of kzalloc()

2023-06-28T11:57:09Z

zcrypt_unlocked_ioctl() allocates 256k with kzalloc() which is likely to fail if memory is fragmented. To avoid that use kvmalloc_array() instead, like it is done at several other places for the same reason. Reviewed-by: Harald Freudenberger Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev

s390/vfio-ap: wire in the vfio_device_ops request callback

2023-06-06T11:42:07Z

The mdev device is being removed, so pass the request to userspace to ask for a graceful cleanup. This should free up the thread that would otherwise loop waiting for the device to be fully released. Signed-off-by: Tony Krowiak Reviewed-by: Cédric Le Goater Reviewed-by: Matthew Rosato Tested-by: Matthew Rosato Acked-by: Alex Williamson Link: https://lore.kernel.org/r/20230530223538.279198-4-akrowiak@linux.ibm.com Signed-off-by: Alexander Gordeev

s390/vfio-ap: realize the VFIO_DEVICE_SET_IRQS ioctl

2023-06-06T11:42:07Z

Realize the VFIO_DEVICE_SET_IRQS ioctl to set an eventfd file descriptor to be used by the vfio_ap device driver to signal a device request to userspace. Signed-off-by: Tony Krowiak Reviewed-by: Cédric Le Goater Reviewed-by: Matthew Rosato Tested-by: Matthew Rosato Link: https://lore.kernel.org/r/20230530223538.279198-3-akrowiak@linux.ibm.com Signed-off-by: Alexander Gordeev

s390/vfio-ap: realize the VFIO_DEVICE_GET_IRQ_INFO ioctl

2023-06-06T11:42:06Z

Realize the VFIO_DEVICE_GET_IRQ_INFO ioctl to retrieve the information for the VFIO device request IRQ. Signed-off-by: Tony Krowiak Acked-by: Alex Williamson Reviewed-by: Cédric Le Goater Reviewed-by: Matthew Rosato Tested-by: Matthew Rosato Link: https://lore.kernel.org/r/20230530223538.279198-2-akrowiak@linux.ibm.com Signed-off-by: Alexander Gordeev

s390/pkey: add support for ecc clear key

2023-06-01T15:10:21Z

Add support for a new 'non CCA clear key token' with these ECC clear keys supported: - ECC P256 - ECC P384 - ECC P521 - ECC ED25519 - ECC ED448 This makes it possible to derive a protected key from this ECC clear key input via PKEY_KBLOB2PROTK3 ioctl. As of now the only way to derive protected keys from these clear key tokens is via PCKMO instruction. For AES keys an alternate path via creating a secure key from the clear key and then derive a protected key from the secure key exists. This alternate path is not implemented for ECC keys as it would require to rearrange and maybe recalculate the clear key material for input to derive an CCA or EP11 ECC secure key. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Alexander Gordeev