Add missing __user annotations to get rid of a couple of sparse
warnings. All callers actually pass kernel pointers instead of user
space pointers, however the pointers are being used within
KERNEL_DS. So everything is fine.
Corresponding sparse warnings:
drivers/s390/crypto/pkey_api.c:181:41:
warning: incorrect type in assignment (different address spaces)
expected char [noderef] <asn:1>*request_control_blk_addr
got void *<noident>
Cc: Harald Freudenberger <freude@linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
drivers/s390/crypto/pkey_api.c:1197:12:
warning: symbol 'pkey_init' was not declared. Should it be static?
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
User space needs some information about the secure key(s)
before actually invoking the pkey and/or paes funcionality.
This patch introduces a new ioctl API and in kernel API to
verify the the secure key blob and give back some
information about the key (type, bitsize, old MKVP).
Both APIs are described in detail in the header files
arch/s390/include/asm/pkey.h and arch/s390/include/uapi/asm/pkey.h.
Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
When a secure key with an old Master Key Verification
Pattern was given to the pkey_findcard function, there was
no responsible card found because only the current MKVP of
each card was compared. With this fix also the old MKVP
values are considered and so a matching card able to handle
the key is reported back to the caller.
Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
This patch introcudes a new kernel module pkey which is providing
protected key handling and management functions. The pkey API is
available within the kernel for other s390 specific code to create
and manage protected keys. Additionally the functions are exported
to user space via IOCTL calls. The implementation makes extensive
use of functions provided by the zcrypt device driver. For
generating protected keys from secure keys there is also a CEX
coprocessor card needed.
Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Heiko Carstens