aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/s390/crypto/zcrypt_ccamisc.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2022-04-25s390/zcrypt: code cleanupHarald Freudenberger1-134/+135
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: <xcRB> 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 <freude@linux.ibm.com> Reviewed-by: Jürgen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-04-25s390/zcrypt: add display of ASYM master key verification patternHarald Freudenberger1-0/+9
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 <freude@linux.ibm.com> Reviewed-by: Jörg Schmidbauer <jschmidb@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-18s390/zcrypt: fix wrong offset index for APKA master key valid stateHarald Freudenberger1-4/+4
Tests showed a mismatch between what the CCA tool reports about the APKA master key state and what's displayed by the zcrypt dd in sysfs. After some investigation, we found out that the documentation which was the source for the zcrypt dd implementation lacks the listing of 3 fields. So this patch now moves the evaluation of the APKA master key state to the correct offset. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-28s390/zcrypt: Switch to flexible array memberKees Cook1-3/+3
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally reading/writing across neighboring array fields. Switch from zero-element arrays to flexible arrays so the compiler will perform appropriate bounds checking, avoiding these future warnings: In function '__fortify_memcpy', inlined from 'cca_sec2protkey' at drivers/s390/crypto/zcrypt_ccamisc.c:645:2: ./include/linux/fortify-string.h:244:4: error: call to '__write_overflow_field' declared with attribute error: detected write beyond size of field (1st parameter) In function '__fortify_memcpy', inlined from 'cca_clr2seckey' at drivers/s390/crypto/zcrypt_ccamisc.c:568:3: ./include/linux/fortify-string.h:246:4: error: call to '__read_overflow2_field' declared with attribute error: detected read beyond size of field (2nd parameter) In function '__fortify_memcpy', inlined from 'cca_genseckey' at drivers/s390/crypto/zcrypt_ccamisc.c:429:2: ./include/linux/fortify-string.h:246:4: error: call to '__read_overflow2_field' declared with attribute error: detected read beyond size of field (2nd parameter) Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210616201903.1245949-1-keescook@chromium.org Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390/crypto: fix function/prototype mismatchesSven Schnelle1-4/+4
gcc-11 warns: drivers/s390/crypto/zcrypt_ccamisc.c:298:38: warning: argument 4 of type u8[64] {aka unsigned char[64]} with mismatched bound [-Warray-parameter=] 298 | u32 keybitsize, u8 seckey[SECKEYBLOBSIZE]) | ~~~^~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/s390/crypto/zcrypt_ccamisc.c:24: drivers/s390/crypto/zcrypt_ccamisc.h:162:63: note: previously declared as u8 * {aka unsigned char *} 162 | int cca_genseckey(u16 cardnr, u16 domain, u32 keybitsize, u8 *seckey); | ~~~~^~~~~~ drivers/s390/crypto/zcrypt_ccamisc.c:441:41: warning: argument 5 of type u8[64] {aka unsigned char[64]} with mismatched bound [-Warray-parameter=] 441 | const u8 *clrkey, u8 seckey[SECKEYBLOBSIZE]) | ~~~^~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/s390/crypto/zcrypt_ccamisc.c:24: drivers/s390/crypto/zcrypt_ccamisc.h:168:42: note: previously declared as u8 * {aka unsigned char *} 168 | const u8 *clrkey, u8 *seckey); | ~~~~^~~~~~ Fix this by making the prototypes match the functions. Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Cc: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-01-27s390/crypto: improve retry logic in case of master key changeHarald Freudenberger1-3/+12
A master key change on a CCA card may cause an immediately following request to derive an protected key from a secure key to fail with error condition 8/2290. The recommendation from firmware is to retry with 1 second sleep. So now the low level cca functions return -EAGAIN when this error condition is seen and the paes retry function will evaluate the return value. Seeing EAGAIN and running in process context results in trying to sleep for 1 s now. 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>
2020-10-16Merge tag 's390-5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds1-107/+304
Pull s390 updates from Vasily Gorbik: - Remove address space overrides using set_fs() - Convert to generic vDSO - Convert to generic page table dumper - Add ARCH_HAS_DEBUG_WX support - Add leap seconds handling support - Add NVMe firmware-assisted kernel dump support - Extend NVMe boot support with memory clearing control and addition of kernel parameters - AP bus and zcrypt api code rework. Add adapter configure/deconfigure interface. Extend debug features. Add failure injection support - Add ECC secure private keys support - Add KASan support for running protected virtualization host with 4-level paging - Utilize destroy page ultravisor call to speed up secure guests shutdown - Implement ioremap_wc() and ioremap_prot() with MIO in PCI code - Various checksum improvements - Other small various fixes and improvements all over the code * tag 's390-5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (85 commits) s390/uaccess: fix indentation s390/uaccess: add default cases for __put_user_fn()/__get_user_fn() s390/zcrypt: fix wrong format specifications s390/kprobes: move insn_page to text segment s390/sie: fix typo in SIGP code description s390/lib: fix kernel doc for memcmp() s390/zcrypt: Introduce Failure Injection feature s390/zcrypt: move ap_msg param one level up the call chain s390/ap/zcrypt: revisit ap and zcrypt error handling s390/ap: Support AP card SCLP config and deconfig operations s390/sclp: Add support for SCLP AP adapter config/deconfig s390/ap: add card/queue deconfig state s390/ap: add error response code field for ap queue devices s390/ap: split ap queue state machine state from device state s390/zcrypt: New config switch CONFIG_ZCRYPT_DEBUG s390/zcrypt: introduce msg tracking in zcrypt functions s390/startup: correct early pgm check info formatting s390: remove orphaned extern variables declarations s390/kasan: make sure int handler always run with DAT on s390/ipl: add support to control memory clearing for nvme re-IPL ...
2020-09-24s390/pkey: support CCA and EP11 secure ECC private keysHarald Freudenberger1-0/+193
This patch extends the pkey kernel module to support CCA and EP11 secure ECC (private) keys as source for deriving ECC protected (private) keys. There is yet another new ioctl to support this: PKEY_KBLOB2PROTK3 can handle all the old keys plus CCA and EP11 secure ECC keys. For details see ioctl description in pkey.h. The CPACF unit currently only supports a subset of 5 different ECC curves (P-256, P-384, P-521, ED25519, ED448) and so only keys of this curve type can be transformed into protected keys. However, the pkey and the cca/ep11 low level functions do not check this but simple pass-through the key blob to the firmware onto the crypto cards. So most likely the failure will be a response carrying an error code resulting in user space errno value EIO instead of EINVAL. Deriving a protected key from an EP11 ECC secure key requires a CEX7 in EP11 mode. Deriving a protected key from an CCA ECC secure key requires a CEX7 in CCA mode. Together with this new ioctl the ioctls for querying lists of apqns (PKEY_APQNS4K and PKEY_APQNS4KT) have been extended to support EP11 and CCA ECC secure key type and key blobs. Together with this ioctl there comes a new struct ep11kblob_header which is to be prepended onto the EP11 key blob. See details in pkey.h for the fields in there. The older EP11 AES key blob with some info stored in the (unused) session field is also supported with this new ioctl. 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>
2020-09-24s390/zcrypt: Support for CCA APKA master keysHarald Freudenberger1-29/+56
Support for CCA APKA (used for CCA ECC keys) master keys. The existing mkvps sysfs attribute for each queue for cards in CCA mode is extended to show the APKA master key register states and verification pattern: Improve the mkvps sysfs attribute to display the APKA master key verification patterns for old, current and new master key registers. The APKA master key is used to encrypt CCA ECC secure keys. The syntax is analog to the existing AES mk verification patterns: APKA NEW: <new_apka_mk_state> <new_apka_mk_mkvp> APKA CUR: <cur_apka_mk_state> <cur_apka_mk_mkvp> APKA OLD: <old_apka_mk_state> <old_apka_mk_mkvp> with <new_apka_mk_state>: 'empty' or 'partial' or 'full' <cur_apka_mk_state>: 'valid' or 'invalid' <old_apka_mk_state>: 'valid' or 'invalid' <new_apka_mk_mkvp>, <cur_apka_mk_mkvp>, <old_apka_mk_mkvp> 8 byte hex string with leading 0x MKVP means Master Key Verification Pattern and is a folded hash over the key value. Only the states 'full' and 'valid' result in displaying a useful mkvp, otherwise a mkvp of all bytes zero is shown. If for any reason the FQ fails and the (cached) information is not available, the state '-' will be shown with the mkvp value also '-'. The values shown here are the very same as the cca panel tools displays. The internal function cca_findcard2() also supports to match against the APKA master key verification patterns and the pkey kernel module which uses this function needed compatible rewrite of these invocations. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2020-09-17s390/zcrypt: remove set_fs() invocation in zcrypt device driverHarald Freudenberger1-25/+7
This patch reworks the zcrypt device driver so that the set_fs() invocation is not needed any more. Instead there is a new flag bool userspace passed through all the functions which tells if the pointer arguments are userspace or kernelspace. Together with the two new inline functions z_copy_from_user() and z_copy_to_user() which either invoke copy_from_user (userspace is true) or memcpy (userspace is false) the zcrypt dd and the AP bus now has no requirement for the set_fs() functionality any more. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2020-09-14s390/zcrypt: simplify cca_findcard2 loop codeHarald Freudenberger1-63/+58
Instead of two times go through the list of available AP devices (which may be up to 256 * 256 entries) this patch reworks the code do only run through once. The price is instead of reporting all possible devices to the caller only the first 256 devices are collected. However, having to choose from 256 AP devices is plenty of resources and should fulfill the caller's requirements. On the other side the loop code is much simplier and more easy to maintain. 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>
2020-09-14s390/zcrypt: fix kmalloc 256k failureHarald Freudenberger1-4/+4
Tests showed that under stress conditions the kernel may temporary fail to allocate 256k with kmalloc. However, this fix reworks the related code in the cca_findcard2() function to use kvmalloc instead. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Cc: Stable <stable@vger.kernel.org> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2020-07-03s390/zcrypt: code beautification and struct field renamesHarald Freudenberger1-31/+38
Some beautifications related to the internal only used struct ap_message and related code. Instead of one int carrying only the special flag now a u32 flags field is used. At struct CPRBX the pointers to additional data are now marked with __user. This caused some changes needed on code, where these 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 <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2020-03-27s390/zcrypt: use kvmalloc instead of kmalloc for 256k allocHarald Freudenberger1-4/+4
Tests showed that it may happen that a 256k kmalloc may fail due to a temporary shortage on 256k slab entries. The find functions for cca and ep11 use a 256k array to fetch the states of all possible crypto cards and their domains in one piece. With the patch now kvmalloc is used to allocate this temporary memory as there is no need to have this memory area physical continuously. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2020-02-17s390/zcrypt: Support for CCA protected key block version 2Harald Freudenberger1-12/+13
There will come a new CCA keyblock version 2 for protected keys delivered back to the OS. The difference is only the amount of available buffer space to be up to 256 bytes for version 2. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2020-01-09s390/zcrypt: Fix CCA cipher key gen with clear key value functionHarald Freudenberger1-2/+2
Regression tests showed that the CCA cipher key function which generates an CCA cipher key with given clear key value does not work correctly. At parsing the reply CPRB two limits are wrong calculated resulting in rejecting the reply as invalid with s390dbf message "_ip_cprb_helper reply with invalid or unknown key block". Fixes: f2bbc96e7cfa ("s390/pkey: add CCA AES cipher key support") Cc: Stable <stable@vger.kernel.org> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-29s390/zcrypt: fix wrong handling of cca cipher keygenflagsHarald Freudenberger1-1/+2
Tests showed that the keygenflags parameter is not handled correctly within the zcrypt ccamisc generate cca cipher key code. A similar code is used with cca cipher key value import and there the flags are handled correctly. For unknown reason these lines have not been updated for the generate function and so this patch now introduces these two lines of code. This affects only pkey with the use of CCA cipher keys and the use of additional key generate flags. Fixes: 4bc123b18ce6 ("s390/zcrypt: Add low level functions for CCA AES cipher keys") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21s390/pkey: add CCA AES cipher key supportHarald Freudenberger1-24/+34
Introduce new ioctls and structs to be used with these new ioctls which are able to handle CCA AES secure keys and CCA AES cipher keys: PKEY_GENSECK2: Generate secure key, version 2. Generate either a CCA AES secure key or a CCA AES cipher key. PKEY_CLR2SECK2: Generate secure key from clear key value, version 2. Construct a CCA AES secure key or CCA AES cipher key from a given clear key value. PKEY_VERIFYKEY2: Verify the given secure key, version 2. Check for correct key type. If cardnr and domain are given, also check if this apqn is able to handle this type of key. If cardnr and domain are 0xFFFF, on return these values are filled with an apqn able to handle this key. The function also checks for the master key verification patterns of the key matching to the current or alternate mkvp of the apqn. CCA AES cipher keys are also checked for CPACF export allowed (CPRTCPAC flag). Currently CCA AES secure keys and CCA AES cipher keys are supported (may get extended in the future). PKEY_KBLOB2PROTK2: Transform a key blob (of any type) into a protected key, version 2. Difference to version 1 is only that this new ioctl has additional parameters to provide a list of apqns to be used for the transformation. PKEY_APQNS4K: Generate a list of APQNs based on the key blob given. Is able to find out which type of secure key is given (CCA AES secure key or CCA AES cipher key) and tries to find all matching crypto cards based on the MKVP and maybe other criterias (like CCA AES cipher keys need a CEX6C or higher). The list of APQNs is further filtered by the key's mkvp which needs to match to either the current mkvp or the alternate mkvp (which is the old mkvp on CCA adapters) of the apqns. The flags argument may be used to limit the matching apqns. If the PKEY_FLAGS_MATCH_CUR_MKVP is given, only the current mkvp of each apqn is compared. Likewise with the PKEY_FLAGS_MATCH_ALT_MKVP. If both are given it is assumed to return apqns where either the current or the alternate mkvp matches. If no matching APQN is found, the ioctl returns with 0 but the apqn_entries value is 0. PKEY_APQNS4KT: Generate a list of APQNs based on the key type given. Build a list of APQNs based on the given key type and maybe further restrict the list by given master key verification patterns. For different key types there may be different ways to match the master key verification patterns. For CCA keys (CCA data key and CCA cipher key) the first 8 bytes of cur_mkvp refer to the current mkvp value of the apqn and the first 8 bytes of the alt_mkvp refer to the old mkvp. The flags argument controls if the apqns current and/or alternate mkvp should match. If the PKEY_FLAGS_MATCH_CUR_MKVP is given, only the current mkvp of each apqn is compared. Likewise with the PKEY_FLAGS_MATCH_ALT_MKVP. If both are given, it is assumed to return apqns where either the current or the alternate mkvp matches. If no matching APQN is found, the ioctl returns with 0 but the apqn_entries value is 0. These new ioctls are now prepared for another new type of secure key blob which may come in the future. They all use a pointer to the key blob and a key blob length information instead of some hardcoded byte array. They all use the new enums pkey_key_type, pkey_key_size and pkey_key_info for getting/setting key type, key size and additional info about the key. All but the PKEY_VERIFY2 ioctl now work based on a list of apqns. This list is walked through trying to perform the operation on exactly this apqn without any further checking (like card type or online state). If the apqn fails, simple the next one in the list is tried until success (return 0) or the end of the list is reached (return -1 with errno ENODEV). All apqns in the list need to be exact apqns (0xFFFF as any card or domain is not allowed). There are two new ioctls which can be used to build a list of apqns based on a key or key type and maybe restricted by match to a current or alternate master key verifcation pattern. 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: Add low level functions for CCA AES cipher keysHarald Freudenberger1-3/+797
This patch adds low level functions, structs and defines to support CCA AES cipher keys: - struct cipherkeytoken can be used for an inside view of the CCA AES cipher key token blob. - function cca_cipher2protkey() derives an CPACF protected key from an CCA AES cipher key. - function cca_gencipherkey() generates an CCA AES cipher key with random value. - function cca_findcard2() constructs a list of apqns based on input constrains like min hardware type, mkvp values. - cca_check_secaescipherkey() does a check on the given CCA AES cipher key blob. - cca_clr2cipherkey() generates an CCA AES cipher key from a given clear key value. 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-18/+51
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>
2019-07-29s390/zcrypt: new sysfs attributes serialnr and mkvpsHarald Freudenberger1-13/+20
This patch extends the sysfs interface with two new attributes for the CEX4, CEX5 and CEX6 crypto cards/queues in coprocessor ('CCA') mode: /sys/devices/ap/cardxx/serialnr /sys/devices/ap/cardxx/xx.yyyy/mkvps The serialnr attribute is card based and shows the 8 character ASCII serial number string which should unique identify the card. The mkvps is queue based and displays 3 lines of information about the new, current and old master key register: AES NEW: <new_aes_mk_state> <new_aes_mk_mkvp> AES CUR: <cur_aes_mk_state> <cur_aes_mk_mkvp> AES OLD: <old_aes_mk_state> <old_aes_mk_mkvp> with <new_aes_mk_state>: 'empty' or 'partial' or 'full' <cur_aes_mk_state>: 'valid' or 'invalid' <old_aes_mk_state>: 'valid' or 'invalid' <new_aes_mk_mkvp>, <cur_aes_mk_mkvp>, <old_aes_mk_mkvp> 8 byte hex string with leading 0x MKVP means Master Key Verification Pattern and is a folded hash over the key value. Only the states 'full' and 'valid' result in displaying a useful mkvp, otherwise a mkvp of all bytes zero is shown. If for any reason the FQ fails and the (cached) information is not available, the state '-' will be shown with the mkvp value also '-'. The values shown here are the very same as the cca panel tools displays. As of now only the AES master keys states and verification patterns are shown. A CCA APQN also has similar master key registers for DES, RSA and ECC. So the content of this attribute may get extended. Reading the sysfs attribute automatically triggers an FQ CPRB to be sent to the queue as long as the queue is (soft-) online. For the serialnr attribute the queue with the default domain id is addressed (if available and valid). This is reasonable as it is assumed that this sysfs interface is not performance critical and on the other side a master key change should be visiable as soon as possible. When a queue is (soft-) offline however, the cached values are displayed. If no cached values are available, the serial number string will be empty and the mkvp lines will show state '-' and mkvp value '-'. 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-07-29s390/zcrypt: add base code for cca crypto card info supportHarald Freudenberger1-56/+75
This patch widens the information held for cca crypto apqns. Currently the current and old master key verification pattern is used by the existing code. Now the new master key registers mkvp, the 8 byte serial number and state info about each master key register is part of the cca info cache. In a next step this information will be used to provide some additional attributes in sysfs for each CCA crypto adapter. 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-07-29s390/zcrypt: move cca misc functions to new code fileHarald Freudenberger1-0/+901
Rework of the pkey code. Moved all the cca generic code away from pkey_api.c into a new file zcrypt_ccamisc.c. This new file is now part of the zcrypt device driver and exports a bunch of cca functions to pkey and may be called from other kernel modules as well. The pkey ioctl API is unchanged. 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>