aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/s390/crypto/zcrypt_api.h (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-09-19s390/zcrypt: CEX7S exploitation supportHarald Freudenberger1-1/+2
This patch adds CEX7 exploitation support for the AP bus code, the zcrypt device driver zoo and the vfio device driver. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21s390/zcrypt: extend cca_findcard function and helperHarald Freudenberger1-5/+2
Rework and extension of the cca_findcard function to be prepared for other types of secure key blobs. Split the function and extract an internal function which has no awareness of key blobs any more. Improve this function and the helper code around to be able to check for a minimal crypto card hardware level (Background: the newer AES cipher keys need to match to the master key verification pattern and need to have a crypto card CEX6 or higher). No API change, neither for the in-kernel API nor the ioctl interface. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2018-10-09s390/zcrypt: zcrypt device driver cleanupHarald Freudenberger1-13/+2
Some 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 <freude@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-08-20s390/zcrypt: code beautifyHarald Freudenberger1-1/+1
Code 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 macros No functional code changes or API changes! Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-04-11s390/zcrypt: Support up to 256 crypto adapters.Harald Freudenberger1-1/+1
There was an artificial restriction on the card/adapter id to only 6 bits but all the AP commands do support adapter ids with 8 bit. This patch removes this restriction to 64 adapters and now up to 256 adapter can get addressed. Some of the ioctl calls work on the max number of cards possible (which was 64). These ioctls are now deprecated but still supported. All the defines, structs and ioctl interface declarations have been kept for compabibility. There are now new ioctls (and defines for these) with an additional '2' appended which provide the extended versions with 256 cards supported. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-04-10s390/zcrypt: Remove deprecated ioctls.Harald Freudenberger1-24/+0
This patch removes the old status calls which have been marked as deprecated since at least 2 years now. There is no known application or library relying on these ioctls any more. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-11-24s390: crypto: Remove redundant license textGreg Kroah-Hartman1-14/+0
Now that the SPDX tag is in all drivers/s390/crypto/ files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Cc: Harald Freudenberger <freude@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-11-24s390: crypto: add SPDX identifiers to the remaining filesGreg Kroah-Hartman1-0/+1
It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the drivers/s390/crypto/ files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Harald Freudenberger <freude@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-10-23s390/zcrypt: CEX6S exploitationHarald Freudenberger1-0/+1
This patch adds the full CEX6S card support to the zcrypt device driver. A CEX6A/C/P is detected and displayed as such, the card and queue device driver code is updated to recognize it and the relative weight values for CEX4, CEX5 and CEX6 have been updated. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-02-23s390/zcrypt: export additional symbolsHarald Freudenberger1-0/+2
Export the two zcrypt device driver functions zcrypt_send_cprb and zcrypt_device_status_mask to be useable for other kernel code. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-12-14s390/zcrypt: Rework debug feature invocations.Harald Freudenberger1-8/+0
Rework the debug feature calls and initialization. There are now two debug feature entries used by the zcrypt code. The first is 'ap' with all the AP bus related stuff and the second is 'zcrypt' with all the zcrypt and devices and driver related entries. However, there isn't much traffic on both debug features. The ap bus code emits only some debug info and for zcrypt devices on appearance and disappearance there is an entry written. The new dbf invocations use the sprintf buffer layout, whereas the old implementation used the ascii dbf buffer. There are now 5*8=40 bytes used for each entry, resulting in 5 parameters per call. As the sprintf buffer needs a format string the first parameter provides this and so up to 4 more parameters can be used. Alltogehter the new layout should be much more human readable for customers and test. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-12-14s390/zcrypt: add multi domain supportIngo Tuchscherer1-20/+64
Currently the ap infrastructure only supports one domain at a time. This feature extends the generic cryptographic device driver to support multiple cryptographic domains simultaneously. There are now card and queue devices on the AP bus with independent card and queue drivers. The new /sys layout is as follows: /sys/bus/ap devices <xx>.<yyyy> -> ../../../devices/ap/card<xx>/<xx>.<yyyy> ... card<xx> -> ../../../devices/ap/card<xx> ... drivers <drv>card card<xx> -> ../../../../devices/ap/card<xx> <drv>queue <xx>.<yyyy> -> ../../../../devices/ap/card<xx>/<xx>.<yyyy> ... /sys/devices/ap card<xx> <xx>.<yyyy> driver -> ../../../../bus/ap/drivers/<zzz>queue ... driver -> ../../../bus/ap/drivers/<drv>card ... The two digit <xx> field is the card number, the four digit <yyyy> field is the queue number and <drv> is the name of the device driver, e.g. "cex4". For compatability /sys/bus/ap/card<xx> for the old layout has to exist, including the attributes that used to reside there. With additional contributions from Harald Freudenberger and Martin Schwidefsky. Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-12-14s390/zcrypt: Introduce workload balancingIngo Tuchscherer1-4/+22
Crypto requests are very different in complexity and thus runtime. Also various crypto adapters are differ with regard to the execution time. Crypto requests can be balanced much better when the request type and eligible crypto adapters are rated in a more precise granularity. Therefore, request weights and adapter speed rates for dedicated requests will be introduced. Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-12-14s390/zcrypt: simplify message type handlingMartin Schwidefsky1-2/+1
Now that the message type modules are linked with the zcrypt_api into a single module the zcrypt_ops_list is initialized by the module init function of the zcyppt.ko module. After that the list is static and all message types are present. Drop the zcrypt_ops_list_lock spinlock and the module handling in regard to the message types. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-11-11s390/zcrypt: Fix initialisation when zcrypt is built-inSascha Silbe1-0/+1
ap_bus and zcrypt_api assumed module information to always be present and initialisation to be done in module loading order (symbol dependencies). These assumptions don't hold if zcrypt is built-in; THIS_MODULE will be NULL in this case and init call order is linker order, i.e. Makefile order. Fix initialisation order by ordering the object files in the Makefile according to their dependencies, like the module loader would do. Fix message type registration by using a dedicated "name" field rather than piggy-backing on the module ("owner") information. There's no change to the requirement that module name and msgtype name are identical. The existing name macros are used. We don't need any special code for dealing with the drivers being built-in; the generic module support code already does the right thing. Test results: 1. CONFIG_MODULES=y, CONFIG_ZCRYPT=y KVM: boots, no /sys/bus/ap (expected) LPAR with CEX5: boots, /sys/bus/ap/devices/card*/type present 2. CONFIG_MODULES=y, CONFIG_ZCRYPT=m=: KVM: boots, loading zcrypt_cex4 (and ap) fails (expected) LPAR with CEX5: boots, loading =zcrypt_cex4= succeeds, /sys/bus/ap/devices/card*/type present after explicit module loading 3. CONFIG_MODULES unset, CONFIG_ZCRYPT=y: KVM: boots, no /sys/bus/ap (expected) LPAR with CEX5: boots, /sys/bus/ap/devices/card*/type present No further testing (user-space functionality) was done. Fixes: 3b6245fd303f ("s390/zcrypt: Separate msgtype implementation from card modules.") Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-01-23s390/zcrypt: Add support for new crypto express (CEX5S) adapter.Ingo Tuchscherer1-0/+1
Extends the generic cryptographic device driver (zcrypt) to support the Crypto Express 5S adapter. Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-12-18s390/zcrypt: add support for EP11 coprocessor cardsIngo Tuchscherer1-0/+2
This feature extends the generic cryptographic device driver (zcrypt) with a new capability to service EP11 requests for the Crypto Express4S card in EP11 (Enterprise PKCS#11 mode) coprocessor mode. Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-09-26s390/zcryt: Handle AP configuration changesHolger Dengler1-1/+8
Detect external AP bus configuration changes and request an AP device rescan. Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-09-26s390/zcrypt: Separate msgtype implementation from card modules.Holger Dengler1-1/+9
Msgtype implementations are now separated from card specific modules and can be dynamically registered. Existing msgtype implementations are restructured in modules. Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-07-20s390/comments: unify copyright messages and remove file namesHeiko Carstens1-3/+1
Remove the file name from the comment at top of many files. In most cases the file name was wrong anyway, so it's rather pointless. Also unify the IBM copyright statement. We did have a lot of sightly different statements and wanted to change them one after another whenever a file gets touched. However that never happened. Instead people start to take the old/"wrong" statements to use as a template for new files. So unify all of them in one go. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2011-03-31Fix common misspellingsLucas De Marchi1-1/+1
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-01-05[S390] zcrypt: cope with cca restriction of cex3Felix Beck1-0/+1
The cca on the crypto adapter has a restriction in the size of the exponent if a key with a modulus bigger than 2048 bit is used. Thus in that case we have to avoid that the crypto device driver thinks the adapter is defect and sets it offline. Therfore a new member for the zcrypt_device struct called max_exp_bit_length is introduced. This will be set the first time the cca returns the error code function not implemented. If this is done with an adapter twice it will return -EINVAL. Signed-off-by: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-12-07[S390] zcrypt: use definitions for cex3Felix Beck1-0/+2
New definitions are added for CEX3 device types. They will be set in the according probe functions. CEX3 device types will be handled in the same modules as CEX2 device types. In the first step they are the same as CEX2 types, but they can be adjusted for further characteristics of CEX3 easily. Signed-off-by: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Ralph Wuerthner <ralph.wuerthner@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-07-14[S390] Cleanup zcrypt printk messages.Felix Beck1-28/+0
Signed-off-by: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2008-04-17[S390] replace remaining __FUNCTION__ occurrencesHarvey Harrison1-4/+4
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2008-04-17[S390] zcrypt: add support for large random numbersRalph Wuerthner1-0/+8
This patch allows user space applications to access large amounts of truly random data. The random data source is the build-in hardware random number generator on the CEX2C cards. Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2006-09-20[S390] zcrypt secure key cryptography extension.Ralph Wuerthner1-1/+2
Allow the user space to send extended cprb messages directly to the PCIXCC / CEX2C cards. This allows the CCA library to construct special crypto requests that use "secure" keys that are stored on the card. Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2006-09-20[S390] zcrypt user space interface.Martin Schwidefsky1-0/+140
The user space interface of the zcrypt device driver implements the old user space interface as defined by the old z90crypt driver. Everything is there, the /dev/z90crypt misc character device, all the lovely ioctls and the /proc file. Even writing to the z90crypt proc file to configure the crypto device still works. It stands to reason to remove the proc write function someday since a much cleaner configuration via the sysfs is now available. The ap bus device drivers register crypto cards to the zcrypt user space interface. The request router of the user space interface picks one of the registered cards based on the predicted latency for the request and calls the driver via a callback found in the zcrypt_ops of the device. The request router only knows which operations the card can do and the minimum / maximum number of bits a request can have. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>