Commit Graph

7 Commits

Author SHA1 Message Date
Harald Freudenberger
f2bbc96e7c s390/pkey: add CCA AES cipher key support
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-21 12:58:54 +02:00
Ingo Franzki
fb1136d658 s390/pkey: Introduce new API for transforming key blobs
Introduce a new ioctl API and in-kernel API to transform
a variable length key blob of any supported type into a
protected key.

Transforming a secure key blob uses the already existing
function pkey_sec2protk().
Transforming a protected key blob also verifies if the
protected key is still valid. If not, -ENODEV is returned.

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: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-10 07:37:19 +02:00
Ingo Franzki
cb26b9ff71 s390/pkey: Introduce new API for random protected key verification
Introduce a new ioctl API and in-kernel API to verify if a
random protected key is still valid. A protected key is
invalid when its wrapping key verification pattern does not
match the verification pattern of the LPAR. Each time an LPAR
is activated, a new LPAR wrapping key is generated and the
wrapping key verification pattern is updated.
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: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-10 07:37:18 +02:00
Ingo Franzki
a45a5c7d36 s390/pkey: Introduce new API for random protected key generation
This patch introduces a new ioctl API and in-kernel API to
generate a random protected key. The protected key is generated
in a way that the effective clear key is never exposed in clear.
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: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:38 +02:00
Greg Kroah-Hartman
6f52b16c5b License cleanup: add SPDX license identifier to uapi header files with no license
Many user space API headers are missing licensing information, which
makes it hard for compliance tools to determine the correct license.

By default are files without license information under the default
license of the kernel, which is GPLV2.  Marking them GPLV2 would exclude
them from being included in non GPLV2 code, which is obviously not
intended. The user space API headers fall under the syscall exception
which is in the kernels COPYING file:

   NOTE! This copyright does *not* cover user programs that use kernel
   services by normal system calls - this is merely considered normal use
   of the kernel, and does *not* fall under the heading of "derived work".

otherwise syscall usage would not be possible.

Update the files which contain no license information with an SPDX
license identifier.  The chosen identifier is 'GPL-2.0 WITH
Linux-syscall-note' which is the officially assigned identifier for the
Linux syscall exception.  SPDX license identifiers are a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.  See the previous patch in this series for the
methodology of how this patch was researched.

Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-02 11:19:54 +01:00
Harald Freudenberger
e61a6134e7 s390/pkey: Introduce new API for secure key verification
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>
2017-03-22 08:29:13 +01:00
Harald Freudenberger
e80d4af0a3 s390/pkey: Introduce pkey kernel module
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>
2017-02-23 10:06:40 +01:00