kernel/drivers/s390/crypto/zcrypt_cex4.c, branch linux-6.9.y

s390/ap: store TAPQ hwinfo in struct ap_card

2023-11-30T15:24:23Z

As of now the AP card struct held only part of the queue's hwinfo (that is the GR2 register content returned with an TAPQ invocation). This patch reworks struct ap_card to hold the whole hwinfo now. As there is a nice bit field union on top of this ap_tapq_hwinfo struct, all the ugly bit checkings can now get replaced by simple evaluations of the required bit field. Suggested-by: Ingo Franzki Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Alexander Gordeev

s390/zcrypt: update list of EP11 operation modes

2023-09-19T11:26:55Z

Add additional operation mode strings into the EP11 operation mode table. These strings are returned by sysfs entries /sys/devices/ap/cardxx/op_modes and /sys/devices/ap/cardxx/xx.yyyy/op_modes. Signed-off-by: Ingo Franzki Reviewed-by: Harald Freudenberger Signed-off-by: Vasily Gorbik

s390/zcrypt: replace scnprintf with sysfs_emit

2023-03-20T10:12:48Z

Replace scnprintf() with sysfs_emit() and friends where possible. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Reviewed-by: Tony Krowiak Signed-off-by: Heiko Carstens

s390/zcrypt: code cleanup

2022-04-25T11:54:14Z

This patch tries to fix as much as possible of the checkpatch.pl --strict findings: CHECK: Logical continuations should be on the previous line CHECK: No space is necessary after a cast CHECK: Alignment should match open parenthesis CHECK: 'useable' may be misspelled - perhaps 'usable'? WARNING: Possible repeated word: 'is' CHECK: spaces preferred around that '*' (ctx:VxV) CHECK: Comparison to NULL could be written "!msg" CHECK: Prefer kzalloc(sizeof(*zc)...) over kzalloc(sizeof(struct...)...) CHECK: Unnecessary parentheses around resp_type->work CHECK: Avoid CamelCase: There is no functional change comming with this patch, only code cleanup, renaming, whitespaces, indenting, ... but no semantic change in any way. Also the API (zcrypt and pkey header file) is semantically unchanged. Signed-off-by: Harald Freudenberger Reviewed-by: Jürgen Christ Signed-off-by: Heiko Carstens

s390/zcrypt: add display of ASYM master key verification pattern

2022-04-25T11:54:13Z

This patch extends the sysfs attribute mkvps for CCA cards to show the states and master key verification patterns for the old, current and new ASYM master key registers. With this patch now all relevant master key verification patterns related to a CCA HSM are available with the mkvps sysfs attribute. This is a requirement for some exploiters like the kubernetes cex plugin or initrd code needing to verify the master key verification patterns on HSMs before use. A sample output: cat /sys/devices/ap/card04/04.0005/mkvps AES NEW: empty 0x0000000000000000 AES CUR: valid 0xe9a49a58cd039bed AES OLD: valid 0x7d10d17bc8a409c4 APKA NEW: empty 0x0000000000000000 APKA CUR: valid 0x5f2f27aaa2d59b4a APKA OLD: valid 0x82a5e2cd5030d5ec ASYM NEW: empty 0x00000000000000000000000000000000 ASYM CUR: valid 0x650c25a89c27e716d0e692b6c83f10e5 ASYM OLD: valid 0xf8ae2acf8bfc57f0a0957c732c16078b Signed-off-by: Harald Freudenberger Reviewed-by: Jörg Schmidbauer Signed-off-by: Heiko Carstens

s390/zcrypt: CEX8S exploitation support

2022-03-07T23:33:00Z

This patch adds CEX8 exploitation support for the AP bus code, the zcrypt device driver zoo and the vfio device driver. Signed-off-by: Harald Freudenberger Reviewed-by: Jürgen Christ Signed-off-by: Vasily Gorbik

s390/zcrypt: remove incorrect kernel doc indicators

2021-09-08T12:23:31Z

Many comments above functions start with a kernel doc indicator, but the comments are not using kernel doc style. Get rid of the warnings by simply removing the indicator. E.g.: drivers/s390/crypto/zcrypt_msgtype6.c:111: warning: This comment starts with '/**', but isn't a kernel-doc comment. Reviewed-by: Harald Freudenberger Signed-off-by: Heiko Carstens

s390/zcrypt: remove gratuitious NULL check in .remove() callbacks

2021-08-25T09:03:33Z

As .remove() is only called after a successful .probe() call, we can trust that the drvdata is valid. Signed-off-by: Julian Wiedmann Signed-off-by: Harald Freudenberger Signed-off-by: Heiko Carstens

s390/ap: use the common driver-data pointer

2021-08-25T09:03:32Z

The device struct provides a pointer for driver-private data. Use this in the zcrypt drivers (as vfio_ap already does), and then remove the custom pointer from the AP device structs. As really_probe() will always clear the drvdata pointer on error, we no longer have to do so ourselves. Signed-off-by: Julian Wiedmann Signed-off-by: Harald Freudenberger Signed-off-by: Heiko Carstens

s390/AP: support new dynamic AP bus size limit

2021-07-05T10:44:23Z

This patch provides support for new dynamic AP bus message limit with the existing zcrypt device driver and AP bus core code. There is support for a new field 'ml' from TAPQ query. The field gives if != 0 the AP bus limit for this card in 4k chunk units. The actual message size limit per card is shown as a new read-only sysfs attribute. The sysfs attribute /sys/devices/ap/cardxx/max_msg_size shows the upper limit in bytes used by the AP bus and zcrypt device driver for requests and replies send to and received from this card. Currently up to CEX7 support only max 12kB msg size and thus the field shows 12288 meaning the upper limit of a valid msg for this card is 12kB. Please note that the usable payload is somewhat lower and depends on the msg type and thus the header struct which is to be prepended by the zcrypt dd. The dispatcher responsible for choosing the right card and queue is aware of the individual card AP bus message limit. So a request is only assigned to a queue of a card which is able to handle the size of the request (e.g. a 14kB request will never go to a max 12kB card). If no such card is found the ioctl will fail with ENODEV. The reply buffer held by the device driver is determined by the ml field of the TAPQ for this card. If a response from the card exceeds this limit however, the response is not truncated but the ioctl for this request will fail with errno EMSGSIZE to indicate that the device driver has dropped the response because it would overflow the buffer limit. If the request size does not indicate to the dispatcher that an adapter with extended limit is to be used, a random card will be chosen when no specific card is addressed (ANY addressing). This may result in an ioctl failure when the reply size needs an adapter with extended limit but the randomly chosen one is not capable of handling the broader reply size. The user space application needs to use dedicated addressing to forward such a request only to suitable cards to get requests like this processed properly. Signed-off-by: Harald Freudenberger Reviewed-by: Ingo Tuchscherer Signed-off-by: Vasily Gorbik