Changes in zcrypt_msgtype50.c

a7a88eea - s390/zcrypt_msgtype50: Cleanup debug code

Tue, 16 Jul 2024 12:16:38 +0000

s390/zcrypt_msgtype50: Cleanup debug codeThe dynamic debugging provides function names on request. So removeall explicit function strings.Reviewed-by: Harald Freudenberger Signed-off-by: Holger Dengler Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

08b2c370 - s390/zcrypt: introduce dynamic debugging for AP and zcrypt code

Tue, 30 Jan 2024 09:07:28 +0000

s390/zcrypt: introduce dynamic debugging for AP and zcrypt codeThis patch replaces all the s390 debug feature calls withdebug level by dynamic debug calls pr_debug. These callsare much more flexible and each single invocation can getenabled/disabled at runtime wheres the s390 debug featuredebug calls have only one knob - enable or disable all inone bunch. The benefit is especially significant withhigh frequency called functions like the AP bus scan. Inmost debugging scenarios you don't want and need them, butsometimes it is crucial to know exactly when and how longthe AP bus scan took.Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

5ac8c724 - s390/zcrypt: remove CEX2 and CEX3 device drivers

Wed, 28 Jun 2023 10:36:08 +0000

s390/zcrypt: remove CEX2 and CEX3 device driversRemove the legacy device driver code for CEX2 and CEX3 cards.The last machines which are able to handle CEX2 crypto cardsare z10 EC first available 2008 and z10 BC first available 2009.The last machines able to handle a CEX3 crypto card arez196 first available 2010 and z114 first available 2011.Please note that this does not imply to drop CEX2 and CEX3support in general. With older kernels on hardware up to theaforementioned machine models these crypto cards will getsupport by IBM.The removal of the CEX2 and CEX3 device drivers code opens upsome simplifications, for example support for crypto cardswithout rng support can be removed also.Signed-off-by: Harald Freudenberger Acked-by: Heiko Carstens Signed-off-by: Heiko Carstens List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

0fdcc88b - s390/zcrypt: cleanup some debug code

Mon, 19 Jun 2023 14:55:07 +0000

s390/zcrypt: cleanup some debug codeThis patch removes most of the debug code whichis build in when CONFIG_ZCRYPT_DEBUG is enabled.There is no real exploiter for this code any more andat least one ioctl fails with this code enabled.The CONFIG_ZCRYPT_DEBUG kernel config option stillmakes sense as some debug sysfs entries can getenabled with this and maybe long term a new betterdesigned debug and error injection way will getintroduced.This patch only removes code surrounded by the namedkernel config option. This option should by defaultalways be off anyway. The structs and defines removedby the patch have been used only by code surroundedby a CONFIG_ZCRYPT_DEBUG ifdef and thus can be removedalso.In the end this patch removes all the failure-injectionpossibilities which had been available when the kernelhad been build with CONFIG_ZCRYPT_DEBUG. It has neverbeen used that much and was too unflexible anyway.Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Alexander Gordeev List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

8794c596 - s390/zcrypt: rework length information for dqap

Tue, 14 Feb 2023 16:13:18 +0000

s390/zcrypt: rework length information for dqapThe inline ap_dqap function does not return the number ofbytes actually written into the message buffer. The callingcode inspects the AP message header to figure out what kindof AP message has been received and pulls the lengthinformation from this header. This processing may not workcorrectly in cases where only a fragment of the reply isreceived.With this patch the ap_dqap inline function now returnsthe number of actually written bytes in the *length parameter.So the calling function has a chance to compare the number ofreceived bytes against what the AP message header lengthfield states. This is especially useful in cases where amessage could only get partially received.The low level reply processing functions needed some reworkto be able to catch this new length information and compareit the right way. The rework also deals with some situationswhere until now the reply length was not correctly calculatedand/or set.All this has been heavily tested as the modifications onthe reply length information may affect crypto load.Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

003d248f - s390/zcrypt: make psmid unsigned long instead of long long

Sun, 29 Jan 2023 18:45:25 +0000

s390/zcrypt: make psmid unsigned long instead of long longSince s390 kernel build does not support 32 bit build anymore there is no difference between long and long long.So this patch reworks all occurrences of psmid (a 64 bitvalue) to use unsigned long now.Signed-off-by: Harald Freudenberger Acked-by: Heiko Carstens Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

2004b57c - s390/zcrypt: code cleanup

Mon, 04 Apr 2022 15:12:37 +0000

s390/zcrypt: code cleanupThis patch tries to fix as much as possible of thecheckpatch.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, onlycode cleanup, renaming, whitespaces, indenting, ... but nosemantic change in any way. Also the API (zcrypt and pkeyheader file) is semantically unchanged.Signed-off-by: Harald Freudenberger Reviewed-by: Jürgen Christ Signed-off-by: Heiko Carstens List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

383366b5 - s390/zcrypt: Support CPRB minor version T7

Tue, 23 Nov 2021 14:16:06 +0000

s390/zcrypt: Support CPRB minor version T7There is a new CPRB minor version T7 to be supported withthis patch. Together with this the functions which extractthe CPRB data from userspace and prepare the AP message donow check the CPRB minor version and provide some info inthe flag field of the ap message struct for further processing.The 3 functions doing this job have been renamed toprep_cca_ap_msg, prep_ep11_ap_msg and prep_rng_ap_msg toreflect their job better (old was get..fc).This patch also introduces two new flags to be used internalwith the flag field of the struct ap_message:AP_MSG_FLAG_USAGE is set when prep_cca_ap_msg or prep_ep11_ap_msgcome to the conclusion that this is a ordinary crypto load CPRB(which means T2 for CCA CPRBs and no admin bit for EP11 CPRBs).AP_MSG_FLAG_ADMIN is set when prep_cca_ap_msg or prep_ep11_ap_msgthink, this is an administrative (control) crypto load CPRB(which means T3, T5, T6 or T7 for CCA CPRBs and admin bit setfor EP11 CPRBs).Signed-off-by: Harald Freudenberger Reviewed-by: Jürgen Christ Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

d64e5e91 - s390/ap/zcrypt: debug feature improvements

Thu, 11 Nov 2021 13:31:46 +0000

s390/ap/zcrypt: debug feature improvementsThis patch adds some debug feature improvements relatedto some failures happened in the past. With CEX8 the maxrequest and response sizes have been extended but theuser space applications did not rework their code andthus ran into receive buffer issues. This ffdc patchhere helps with additional checks and debug featuremessages in debugging and pointing to the root cause ofsome failures related to wrong buffer sizes.Signed-off-by: Harald Freudenberger Reviewed-by: Jürgen Christ Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

3f74eb5f - s390/zcrypt: rework of debug feature messages

Fri, 15 Oct 2021 10:00:22 +0000

s390/zcrypt: rework of debug feature messagesThis patch reworks all the debug feature invocations to bemore uniform. All invocations now use the macro with thelevel already part of the macro name. All messages now startwith %s filled with __func__ (well there are still someexceptions), and some message text has been shortened orreworked.There is no functional code touched with this patch.Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

2c57ad60 - s390/zcrypt: remove incorrect kernel doc indicators

Tue, 07 Sep 2021 05:28:20 +0000

s390/zcrypt: remove incorrect kernel doc indicatorsMany comments above functions start with a kernel doc indicator, butthe comments are not using kernel doc style. Get rid of the warningsby 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 List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

bd39654a - s390/AP: support new dynamic AP bus size limit

Fri, 25 Jun 2021 10:29:46 +0000

s390/AP: support new dynamic AP bus size limitThis patch provides support for new dynamic AP bus message limitwith the existing zcrypt device driver and AP bus core code.There is support for a new field 'ml' from TAPQ query. The fieldgives 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-onlysysfs attribute. The sysfs attribute /sys/devices/ap/cardxx/max_msg_sizeshows the upper limit in bytes used by the AP bus and zcrypt devicedriver for requests and replies send to and received from this card.Currently up to CEX7 support only max 12kB msg size and thus the fieldshows 12288 meaning the upper limit of a valid msg for this card is12kB. Please note that the usable payload is somewhat lower anddepends on the msg type and thus the header struct which is to beprepended by the zcrypt dd.The dispatcher responsible for choosing the right card and queue isaware of the individual card AP bus message limit. So a request isonly assigned to a queue of a card which is able to handle the size ofthe 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 mlfield of the TAPQ for this card. If a response from the card exceedsthis limit however, the response is not truncated but the ioctl forthis request will fail with errno EMSGSIZE to indicate that the devicedriver has dropped the response because it would overflow the bufferlimit.If the request size does not indicate to the dispatcher that anadapter with extended limit is to be used, a random card will bechosen when no specific card is addressed (ANY addressing). This mayresult in an ioctl failure when the reply size needs an adapter withextended limit but the randomly chosen one is not capable of handlingthe broader reply size. The user space application needs to usededicated addressing to forward such a request only to suitable cardsto get requests like this processed properly.Signed-off-by: Harald Freudenberger Reviewed-by: Ingo Tuchscherer Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

df6f508c - s390/ap/zcrypt: notify userspace with online, config and mode info

Tue, 13 Apr 2021 16:11:09 +0000

s390/ap/zcrypt: notify userspace with online, config and mode infoThis patch brings 3 reworked/new uevent changes:* All AP uevents caused by an ap card or queue device now carry an additional uevent env value MODE=. Here is an example: KERNEL[1267.301292] add /devices/ap/card0a (ap) ACTION=add DEVPATH=/devices/ap/card0a SUBSYSTEM=ap DEVTYPE=ap_card DEV_TYPE=000D MODALIAS=ap:t0D MODE=ep11 <- this is new SEQNUM=1095 This is true for bind, unbind, add, remove, and change uevents related to ap card or ap queue devices.* On a change of the soft online attribute on a zcrypt queue or card device a new CHANGE uevent is sent with an env value ONLINE=<0|1>. Example uevent: KERNEL[613.067531] change /devices/ap/card09/09.0011 (ap) ACTION=change DEVPATH=/devices/ap/card09/09.0011 SUBSYSTEM=ap ONLINE=0 <- this is new DEVTYPE=ap_queue DRIVER=cex4queue MODE=cca SEQNUM=1070- On a change of the config state of an zcrypt card device a new CHANGE uevent is sent with an env value CONFIG=<0|1>. Example uevent: KERNEL[876.258680] change /devices/ap/card09 (ap) ACTION=change DEVPATH=/devices/ap/card09 SUBSYSTEM=ap CONFIG=0 <- this is new DEVTYPE=ap_card DRIVER=cex4card DEV_TYPE=000D MODALIAS=ap:t0D MODE=cca SEQNUM=1073 Setting a card config on/off causes the dependent queue devices to follow the config state change and thus uevents informing about the config state change for the queue devices are also emitted.Signed-off-by: Harald Freudenberger Reviewed-by: Ingo Franzki Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

27c4f673 - s390/zcrypt: Introduce Failure Injection feature

Tue, 29 Sep 2020 14:07:22 +0000

s390/zcrypt: Introduce Failure Injection featureIntroduce a way to specify additional debug flags with an crpytorequest to be able to trigger certain failures within the zcryptdevice drivers and/or ap core code.This failure injection possibility is only enabled with a kernel debugbuild CONFIG_ZCRYPT_DEBUG) and should never be available on a regularkernel running in production environment.Details:* The ioctl(ICARSAMODEXPO) get's a struct ica_rsa_modexpo. If the leftmost bit of the 32 bit unsigned int inputdatalength field is set, the uppermost 16 bits are separated and used as debug flag value. The process is checked to have the CAP_SYS_ADMIN capability enabled or EPERM is returned.* The ioctl(ICARSACRT) get's a struct ica_rsa_modexpo_crt. If the leftmost bit of the 32 bit unsigned int inputdatalength field is set, the uppermost 16 bits are separated and used als debug flag value. The process is checked to have the CAP_SYS_ADMIN capability enabled or EPERM is returned.* The ioctl(ZSECSENDCPRB) used to send CCA CPRBs get's a struct ica_xcRB. If the leftmost bit of the 32 bit unsigned int status field is set, the uppermost 16 bits of this field are used as debug flag value. The process is checked to have the CAP_SYS_ADMIN capability enabled or EPERM is returned.* The ioctl(ZSENDEP11CPRB) used to send EP11 CPRBs get's a struct ep11_urb. If the leftmost bit of the 64 bit unsigned int req_len field is set, the uppermost 16 bits of this field are used as debug flag value. The process is checked to have the CAP_SYS_ADMIN capability enabled or EPERM is returned.So it is possible to send an additional 16 bit value to the zcrypt APIto be used to carry a failure injection command which may triggerspecial behavior within the zcrypt API and layers below. This 16 bitvalue is for the rest of the test referred as 'fi command' for FailureInjection.The lower 8 bits of the fi command construct a numerical argument inthe range of 1-255 and is the 'fi action' to be performed with therequest or the resulting reply:* 0x00 (all requests): No failure injection action but flags may be provided which may affect the processing of the request or reply.* 0x01 (only CCA CPRBs): The CPRB's agent_ID field is set to 'FF'. This results in an reply code 0x90 (Transport-Protocol Failure).* 0x02 (only CCA CPRBs): After the APQN to send to has been chosen, the domain field within the CPRB is overwritten with value 99 to enforce an reply with RY 0x8A.* 0x03 (all requests): At NQAP invocation the invalid qid value 0xFF00 is used causing an response code of 0x01 (AP queue not valid).The upper 8 bits of the fi command may carry bit flags which mayinfluence the processing of an request or response:* 0x01: No retry. If this bit is set, the usual loop in the zcrypt API which retries an CPRB up to 10 times when the lower layers return with EAGAIN is abandoned after the first attempt to send the CPRB.* 0x02: Toggle special. Toggles the special bit on this request. This should result in an reply code RY~0x41 and result in an ioctl failure with errno EINVAL.This failure injection possibilities may get some further extensionsin the future. As of now this is a starting point for Continuous Testand Integration to trigger some failures and watch for the reaction ofthe ap bus and zcrypt device driver code.Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

3730f530 - s390/zcrypt: move ap_msg param one level up the call chain

Sat, 26 Sep 2020 20:51:38 +0000

s390/zcrypt: move ap_msg param one level up the call chainMove the creating and disposal of the struct ap_message onelevel up the call chain. The ap message was constructed in thecalling functions in msgtype50 and msgtype6 but only for theica rsa messages. For CCA and EP11 CPRBs the ap message structis created in the zcrypt api functions.This patch moves the construction of the ap message struct intothe functions zcrypt_rsa_modexpo and zcrypt_rsa_crt. So now allthe 4 zcrypt api functions zcrypt_rsa_modexpo, zcrypt_rsa_crt,zcrypt_send_cprb and zcrypt_send_ep11_cprb appear and actsimilar.There are no functional changes coming with this patch.However, the availability of the ap_message struct hasadvantages which will be needed by a follow up patch.Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

e0332629 - s390/ap/zcrypt: revisit ap and zcrypt error handling

Tue, 04 Aug 2020 07:27:47 +0000

s390/ap/zcrypt: revisit ap and zcrypt error handlingRevisit the ap queue error handling: Based on discussions andevaluatios with the firmware folk here is now a rework of the responsecode handling for all the AP instructions. The idea is to distinguishbetween failures because of some kind of invalid request where a retrydoes not make any sense and a failure where another attempt to sendthe very same request may succeed. The first case is handled byreturning EINVAL to the userspace application. The second case resultsin retries within the zcrypt API controlled by a per message retrycounter.Revisit the zcrpyt error handling: Similar here, based on discussionswith the firmware people here comes a rework of the handling of allthe reply codes. Main point here is that there are only very fewcases left, where a zcrypt device queue is switched to offline. Itshould never be the case that an AP reply message is 'unknown' to thedevice driver as it indicates a total mismatch between device driverand crypto card firmware. In all other cases, the code distinguishesbetween failure because of invalid message (see above - EINVAL) orfailures of the infrastructure (see above - EAGAIN).Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

0b641cbd - s390/ap: split ap queue state machine state from device state

Thu, 02 Jul 2020 09:22:01 +0000

s390/ap: split ap queue state machine state from device stateThe state machine for each ap queue covered a mixture ofdevice states and state machine (firmware queue state) states.This patch splits the device states and the state machinestates into two different enums and variables. The majorstate is the device state with currently these values: AP_DEV_STATE_UNINITIATED - fresh and virgin, not touched AP_DEV_STATE_OPERATING - queue dev is working normal AP_DEV_STATE_SHUTDOWN - remove/unbind/shutdown in progress AP_DEV_STATE_ERROR - device is in error stateonly when the device state is > UNINITIATED the state machineis run. The state machine represents the states of the firmwarequeue: AP_SM_STATE_RESET_START - starting point, reset (RAPQ) ap queue AP_SM_STATE_RESET_WAIT - reset triggered, waiting to be finished if irqs enabled, set up irq (AQIC) AP_SM_STATE_SETIRQ_WAIT - enable irq triggered, waiting to be finished, then go to IDLE AP_SM_STATE_IDLE - queue is operational but empty AP_SM_STATE_WORKING - queue is operational, requests are stored and replies may wait for getting fetched AP_SM_STATE_QUEUE_FULL - firmware queue is full, so only replies can get fetchedFor debugging each ap queue shows a sysfs attribute 'states' whichdisplays the device and state machine state and is only availablewhen the kernel is build with CONFIG_ZCRYPT_DEBUG enabled.Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

74ecbef7 - s390/zcrypt: code beautification and struct field renames

Thu, 30 Apr 2020 10:23:29 +0000

s390/zcrypt: code beautification and struct field renamesSome beautifications related to the internal only usedstruct ap_message and related code. Instead of one int carryingonly the special flag now a u32 flags field is used.At struct CPRBX the pointers to additional data are now markedwith __user. This caused some changes needed on code, wherethese structs are also used within the zcrypt misc functions.The ica_rsa_* structs now use the generic types __u8, __u32, ...instead of char, unsigned int.zcrypt_msg6 and zcrypt_msg50 use min_t() instead of min().Signed-off-by: Harald Freudenberger Signed-off-by: Heiko Carstens List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

ee410de8 - s390/zcrypt: zcrypt device driver cleanup

Thu, 04 Oct 2018 13:30:24 +0000

s390/zcrypt: zcrypt device driver cleanupSome cleanup in the s390 zcrypt device driver:- Removed fragments of pcixx crypto card code. This code can't be reached anymore because the hardware detection function does not recognize crypto cards < CEX2 since commit f56545430736 ("s390/zcrypt: Introduce QACT support for AP bus devices.")- Rename of some files and driver names which where still reflecting pcixx support to cex2a/cex2c.- Removed all the zcrypt version strings in the file headers. There is only one place left - the zcrypt.h header file is now the only place for zcrypt device driver version info.- Zcrypt version pump up from 2.2.0 to 2.2.1.Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c

ac2b96f3 - s390/zcrypt: code beautify

Fri, 17 Aug 2018 10:36:01 +0000

s390/zcrypt: code beautifyCode beautify by following most of the checkpatch suggestions: - SPDX license identifier line complains by checkpatch - missing space or newline complains by checkpatch - octal numbers for permssions complains by checkpatch - renaming of static sysfs functions complains by checkpatch - fix of block comment complains by checkpatch - fix printf like calls where function name instead of %s __func__ was used - __packed instead of __attribute__((packed)) - init to zero for static variables removed - use of DEVICE_ATTR_RO and DEVICE_ATTR_RW macrosNo functional code changes or API changes!Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/drivers/s390/crypto/zcrypt_msgtype50.c