provide paes selftests
Subsystems (5)
Harald Freudenberger
maintainercover provide paes selftests
This patch series provides a reworked version of the paes in-kernel cipher implementation together with the introdution of in-kernel selftests for the ciphers implemented there.
Please note that the paes patch is developed against linux-next respectively Herbert Xu's crypto tree as the fixes from Eric Biggers which move the paes cipers from blkciper to skciper are a requirement for the paes rework.
For more details about each patch please have a look into the individual patch headers.
Harald Freudenberger (3):
s390/pkey: Add support for key blob with clear key value s390/crypto: Rework on paes implementation crypto/testmgr: add selftests for paes-s390
arch/s390/crypto/paes_s390.c | 163 +++++++++---- crypto/testmgr.c | 36 +++ crypto/testmgr.h | 334 +++++++++++++++++++++++++++ drivers/s390/crypto/pkey_api.c | 60 ++++- drivers/s390/crypto/zcrypt_ccamisc.h | 1 + 5 files changed, 545 insertions(+), 49 deletions(-)
Signature · 1 line
2.17.1
Harald Freudenberger
maintainerPATCH 1/3 s390/pkey: Add support for key blob with clear key value
This patch adds support for a new key blob format to the pkey kernel module. The new key blob comprises a clear key value together with key type information.
The implementation tries to derive an protected key from the blob with the clear key value inside with
1) the PCKMO instruction. This may fail as the LPAR profile may disable this way.
2) Generate an CCA AES secure data key with exact the clear key value. This requires to have a working crypto card in CCA Coprocessor mode. Then derive an protected key from the CCA AES secure key again with the help of a working crypto card in CCA mode.
If both way fail, the transformation of the clear key blob into a protected key will fail. For the PAES cipher this would result in a failure at setkey() invocation.
A clear key value exposed in main memory is a security risk. The intention of this new 'clear key blob' support for pkey is to provide self-tests for the PAES cipher key implementation. These known answer tests obviously need to be run with well known key values. So with the clear key blob format there is a way to provide knwon answer tests together with an pkey clear key blob for the in-kernel self tests done at cipher registration.
Reference-ID: SEC1918
--- drivers/s390/crypto/pkey_api.c | 60 +++++++++++++++++++++++++--- drivers/s390/crypto/zcrypt_ccamisc.h | 1 + 2 files changed, 55 insertions(+), 6 deletions(-)
drivers/s390/crypto/pkey_api.c +54 -6
@@ -71,6 +71,17 @@ struct protaeskeytoken {u8 protkey[MAXPROTKEYSIZE ];/* the protected key blob */ } __packed; +/* inside view of a clear key token (type 0x00 version 0x02) */ +struct clearaeskeytoken { +u8 type;/* 0x00 for PAES specific key tokens */ +u8 res0[3 ]; +u8 version;/* 0x02 for clear AES key token */ +u8 res1[3 ]; +u32 keytype;/* key type, one of the PKEY_KEYTYPE values */ +u32 len;/* bytes actually stored in clearkey[] */ +u8 clearkey[0 ];/* clear key value */ +} __packed; +/* * Create a protected key from a clear key value. */
@@ -305,26 +316,63 @@ static int pkey_verifyprotkey(const struct pkey_protkey *protkey)static int pkey_nonccatok2pkey (const u8 *key,u32 keylen,struct pkey_protkey *protkey) { +int rc = -EINVAL ;struct keytoken_header *hdr = (struct keytoken_header *)key; -struct protaeskeytoken *t;switch (hdr->version) { -case TOKVER_PROTECTED_KEY : -if (keylen !=sizeof (struct protaeskeytoken )) -return -EINVAL ; +case TOKVER_PROTECTED_KEY : { +struct protaeskeytoken *t; +if (keylen !=sizeof (struct protaeskeytoken )) + goto out; t = (struct protaeskeytoken *)key; protkey->len = t->len; protkey->type = t->keytype;memcpy (protkey->protkey, t->protkey,sizeof (protkey->protkey)); + rc =pkey_verifyprotkey (protkey); +break ; + } +case TOKVER_CLEAR_KEY : { +struct clearaeskeytoken *t; +struct pkey_clrkey ckey; +struct pkey_seckey skey; -return pkey_verifyprotkey (protkey); +if (keylen <sizeof (struct clearaeskeytoken )) + goto out; + t = (struct clearaeskeytoken *)key; +if (keylen !=sizeof (*t) + t->len) + goto out; +if ((t->keytype ==PKEY_KEYTYPE_AES_128 && t->len ==16 ) + || (t->keytype ==PKEY_KEYTYPE_AES_192 && t->len ==24 ) + || (t->keytype ==PKEY_KEYTYPE_AES_256 && t->len ==32 )) +memcpy (ckey.clrkey, t->clearkey, t->len); +else + goto out; +/* try direct way with the PCKMO instruction */ + rc =pkey_clr2protkey (t->keytype, &ckey, protkey); +if (rc ==0 ) +break ; +/* PCKMO failed, so try the CCA secure key way */ + rc =cca_clr2seckey (0xFFFF ,0xFFFF , t->keytype, + ckey.clrkey, skey.seckey); +if (rc ==0 ) + rc =pkey_skey2pkey (skey.seckey, protkey); +/* now we should really have an protected key */ +if (rc ==0 ) +break ; +DEBUG_ERR ("%s unable to build protected key from clear" , + __func__); +break ; + }default :DEBUG_ERR ("%s unknown/unsupported non-CCA token version %d\n" , __func__, hdr->version); -return -EINVAL ; + rc = -EINVAL ; } + +out: +return rc; }/*
drivers/s390/crypto/zcrypt_ccamisc.h +1 -0
@@ -19,6 +19,7 @@/* For TOKTYPE_NON_CCA: */ #define TOKVER_PROTECTED_KEY 0x01/* Protected key token */ +#define TOKVER_CLEAR_KEY 0x02/* Clear key token */ /* For TOKTYPE_CCA_INTERNAL: */ #define TOKVER_CCA_AES 0x04/* CCA AES key token */
Signature · 1 line
2.17.1
Harald Freudenberger
maintainerPATCH 2/3 s390/crypto: Rework on paes implementation
In reply to Harald FreudenbergerThere have been some findings during Eric Biggers rework of the paes implementation which this patch tries to address:
A very minor finding within paes ctr where when the cpacf instruction returns with only partially data en/decrytped the walk_done() was mistakenly done with the all data counter. Please note this can only happen when the kmctr returns because the protected key became invalid in the middle of the operation. And this is only with suspend and resume on a system with different effective wrapping key.
Eric Biggers mentioned that the context struct within the tfm struct may be shared among multiple kernel threads. So here now a rework which uses a spinlock per context to protect the read and write of the protected key blob value. The en/decrypt functions copy the protected key(s) at the beginning into a param struct and do not work with the protected key within the context any more. If the protected key in the param struct becomes invalid, the key material is again converted to protected key(s) and the context gets this update protected by the spinlock. Race conditions are still possible and may result in writing the very same protected key value more than once. So the spinlock needs to make sure the protected key(s) within the context are consistent updated.
The ctr page is now locked by a mutex instead of a spinlock. A similar patch went into the aes_s390 code as a result of a complain "sleeping function called from invalid context at ...algapi.h". See commit 1c2c7029c008 ("s390/crypto: fix possible sleep during spinlock aquired")' for more. The very same page is now allocated before registration. As the selftest runs during registration the page needs to be available before registration or the kernel would crash.
During testing with instrumented code another issue with the xts en/decrypt function revealed. The retry cleared the running iv value and thus let to wrong en/decrypted data.
Tested and verified with additional testcases via AF_ALG interface and additional selftests within the kernel (which will be made available as an additional patch to the crypto testmgr).
--- arch/s390/crypto/paes_s390.c | 163 ++++++++++++++++++++++++++--------- 1 file changed, 120 insertions(+), 43 deletions(-)
arch/s390/crypto/paes_s390.c +120 -43
@@ -20,6 +20,7 @@#include <linux/module.h> #include <linux/cpufeature.h> #include <linux/init.h> +#include <linux/mutex.h> #include <linux/spinlock.h> #include <crypto/internal/skcipher.h> #include <crypto/xts.h>
@@ -32,11 +33,11 @@* is called. As paes can handle different kinds of key blobs * and padding is also possible, the limits need to be generous. */ -#define PAES_MIN_KEYSIZE 64 +#define PAES_MIN_KEYSIZE 32#define PAES_MAX_KEYSIZE 256static u8 *ctrblk; -static DEFINE_SPINLOCK (ctrblk_lock); +static DEFINE_MUTEX (ctrblk_lock);static cpacf_mask_t km_functions, kmc_functions, kmctr_functions;
@@ -82,17 +83,19 @@ static inline void _free_kb_keybuf(struct key_blob *kb)struct s390_paes_ctx {struct key_blob kb;struct pkey_protkey pk; +spinlock_t pk_lock;unsigned long fc; };struct s390_pxts_ctx {struct key_blob kb[2 ];struct pkey_protkey pk[2 ]; +spinlock_t pk_lock;unsigned long fc; }; -static inline int __paes_convert_key (struct key_blob *kb, -struct pkey_protkey *pk) +static inline int __paes_keyblob2pkey (struct key_blob *kb, +struct pkey_protkey *pk) {int i, ret;
@@ -106,22 +109,18 @@ static inline int __paes_convert_key(struct key_blob *kb,return ret; } -static int __paes_set_key (struct s390_paes_ctx *ctx) +static inline int __paes_convert_key (struct s390_paes_ctx *ctx) { -unsigned long fc; +struct pkey_protkey pkey; -if (__paes_convert_key (&ctx->kb, &ctx->pk)) +if (__paes_keyblob2pkey (&ctx->kb, &pkey))return -EINVAL ; -/* Pick the correct function code based on the protected key type */ - fc = (ctx->pk.type ==PKEY_KEYTYPE_AES_128 ) ?CPACF_KM_PAES_128 : - (ctx->pk.type ==PKEY_KEYTYPE_AES_192 ) ?CPACF_KM_PAES_192 : - (ctx->pk.type ==PKEY_KEYTYPE_AES_256 ) ?CPACF_KM_PAES_256 :0 ; +spin_lock_bh (&ctx->pk_lock); +memcpy (&ctx->pk, &pkey,sizeof (pkey)); +spin_unlock_bh (&ctx->pk_lock); -/* Check if the function code is available */ - ctx->fc = (fc &&cpacf_test_func (&km_functions, fc)) ? fc :0 ; - -return ctx->fc ?0 : -EINVAL ; +return 0 ; }static int ecb_paes_init (struct crypto_skcipher *tfm)
@@ -129,6 +128,7 @@ static int ecb_paes_init(struct crypto_skcipher *tfm)struct s390_paes_ctx *ctx =crypto_skcipher_ctx (tfm); ctx->kb.key =NULL ; +spin_lock_init (&ctx->pk_lock);return 0 ; }
@@ -140,6 +140,24 @@ static void ecb_paes_exit(struct crypto_skcipher *tfm)_free_kb_keybuf (&ctx->kb); } +static inline int __ecb_paes_set_key (struct s390_paes_ctx *ctx) +{ +unsigned long fc; + +if (__paes_convert_key (ctx)) +return -EINVAL ; + +/* Pick the correct function code based on the protected key type */ + fc = (ctx->pk.type ==PKEY_KEYTYPE_AES_128 ) ?CPACF_KM_PAES_128 : + (ctx->pk.type ==PKEY_KEYTYPE_AES_192 ) ?CPACF_KM_PAES_192 : + (ctx->pk.type ==PKEY_KEYTYPE_AES_256 ) ?CPACF_KM_PAES_256 :0 ; + +/* Check if the function code is available */ + ctx->fc = (fc &&cpacf_test_func (&km_functions, fc)) ? fc :0 ; + +return ctx->fc ?0 : -EINVAL ; +} +static int ecb_paes_set_key (struct crypto_skcipher *tfm,const u8 *in_key,unsigned int key_len) {
@@ -151,7 +169,7 @@ static int ecb_paes_set_key(struct crypto_skcipher *tfm, const u8 *in_key,if (rc)return rc; -if (__paes_set_key (ctx)) { +if (__ecb_paes_set_key (ctx)) {crypto_skcipher_set_flags (tfm,CRYPTO_TFM_RES_BAD_KEY_LEN );return -EINVAL ; }
@@ -165,18 +183,31 @@ static int ecb_paes_crypt(struct skcipher_request *req, unsigned long modifier)struct skcipher_walk walk;unsigned int nbytes, n, k;int ret; +struct { +u8 key[MAXPROTKEYSIZE ]; + } param; ret =skcipher_walk_virt (&walk, req, false); +if (ret) +return ret; + +spin_lock_bh (&ctx->pk_lock); +memcpy (param.key, ctx->pk.protkey,MAXPROTKEYSIZE ); +spin_unlock_bh (&ctx->pk_lock); +while ((nbytes = walk.nbytes) !=0 ) {/* only use complete blocks */ n = nbytes & ~(AES_BLOCK_SIZE -1 ); - k =cpacf_km (ctx->fc | modifier, ctx->pk.protkey, + k =cpacf_km (ctx->fc | modifier, ¶m, walk.dst.virt.addr, walk.src.virt.addr, n);if (k) ret =skcipher_walk_done (&walk, nbytes - k);if (k < n) { -if (__paes_set_key (ctx) !=0 ) +if (__paes_convert_key (ctx))return skcipher_walk_done (&walk, -EIO ); +spin_lock_bh (&ctx->pk_lock); +memcpy (param.key, ctx->pk.protkey,MAXPROTKEYSIZE ); +spin_unlock_bh (&ctx->pk_lock); } }return ret;
@@ -214,6 +245,7 @@ static int cbc_paes_init(struct crypto_skcipher *tfm)struct s390_paes_ctx *ctx =crypto_skcipher_ctx (tfm); ctx->kb.key =NULL ; +spin_lock_init (&ctx->pk_lock);return 0 ; }
@@ -225,11 +257,11 @@ static void cbc_paes_exit(struct crypto_skcipher *tfm)_free_kb_keybuf (&ctx->kb); } -static int __cbc_paes_set_key (struct s390_paes_ctx *ctx) +static inline int __cbc_paes_set_key (struct s390_paes_ctx *ctx) {unsigned long fc; -if (__paes_convert_key (&ctx->kb, &ctx->pk)) +if (__paes_convert_key (ctx))return -EINVAL ;/* Pick the correct function code based on the protected key type */
@@ -276,8 +308,12 @@ static int cbc_paes_crypt(struct skcipher_request *req, unsigned long modifier) ret =skcipher_walk_virt (&walk, req, false);if (ret)return ret; +memcpy (param.iv, walk.iv,AES_BLOCK_SIZE ); +spin_lock_bh (&ctx->pk_lock);memcpy (param.key, ctx->pk.protkey,MAXPROTKEYSIZE ); +spin_unlock_bh (&ctx->pk_lock); +while ((nbytes = walk.nbytes) !=0 ) {/* only use complete blocks */ n = nbytes & ~(AES_BLOCK_SIZE -1 );
@@ -288,9 +324,11 @@ static int cbc_paes_crypt(struct skcipher_request *req, unsigned long modifier) ret =skcipher_walk_done (&walk, nbytes - k); }if (k < n) { -if (__cbc_paes_set_key (ctx) !=0 ) +if (__paes_convert_key (ctx))return skcipher_walk_done (&walk, -EIO ); +spin_lock_bh (&ctx->pk_lock);memcpy (param.key, ctx->pk.protkey,MAXPROTKEYSIZE ); +spin_unlock_bh (&ctx->pk_lock); } }return ret;
@@ -330,6 +368,7 @@ static int xts_paes_init(struct crypto_skcipher *tfm) ctx->kb[0 ].key =NULL ; ctx->kb[1 ].key =NULL ; +spin_lock_init (&ctx->pk_lock);return 0 ; }
@@ -342,12 +381,27 @@ static void xts_paes_exit(struct crypto_skcipher *tfm)_free_kb_keybuf (&ctx->kb[1 ]); } -static int __xts_paes_set_key (struct s390_pxts_ctx *ctx) +static inline int __xts_paes_convert_key (struct s390_pxts_ctx *ctx) +{ +struct pkey_protkey pkey0, pkey1; + +if (__paes_keyblob2pkey (&ctx->kb[0 ], &pkey0) || +__paes_keyblob2pkey (&ctx->kb[1 ], &pkey1)) +return -EINVAL ; + +spin_lock_bh (&ctx->pk_lock); +memcpy (&ctx->pk[0 ], &pkey0,sizeof (pkey0)); +memcpy (&ctx->pk[1 ], &pkey1,sizeof (pkey1)); +spin_unlock_bh (&ctx->pk_lock); + +return 0 ; +} + +static inline int __xts_paes_set_key (struct s390_pxts_ctx *ctx) {unsigned long fc; -if (__paes_convert_key (&ctx->kb[0 ], &ctx->pk[0 ]) || -__paes_convert_key (&ctx->kb[1 ], &ctx->pk[1 ])) +if (__xts_paes_convert_key (ctx))return -EINVAL ;if (ctx->pk[0 ].type != ctx->pk[1 ].type)
@@ -425,15 +479,17 @@ static int xts_paes_crypt(struct skcipher_request *req, unsigned long modifier) ret =skcipher_walk_virt (&walk, req, false);if (ret)return ret; + keylen = (ctx->pk[0 ].type ==PKEY_KEYTYPE_AES_128 ) ?48 :64 ; offset = (ctx->pk[0 ].type ==PKEY_KEYTYPE_AES_128 ) ?16 :0 ; -retry: +memset (&pcc_param,0 ,sizeof (pcc_param));memcpy (pcc_param.tweak, walk.iv,sizeof (pcc_param.tweak)); +spin_lock_bh (&ctx->pk_lock);memcpy (pcc_param.key + offset, ctx->pk[1 ].protkey, keylen); -cpacf_pcc (ctx->fc, pcc_param.key + offset); -memcpy (xts_param.key + offset, ctx->pk[0 ].protkey, keylen); +spin_unlock_bh (&ctx->pk_lock); +cpacf_pcc (ctx->fc, pcc_param.key + offset);memcpy (xts_param.init, pcc_param.xts,16 );while ((nbytes = walk.nbytes) !=0 ) {
@@ -444,11 +500,15 @@ static int xts_paes_crypt(struct skcipher_request *req, unsigned long modifier)if (k) ret =skcipher_walk_done (&walk, nbytes - k);if (k < n) { -if (__xts_paes_set_key (ctx) !=0 ) +if (__xts_paes_convert_key (ctx))return skcipher_walk_done (&walk, -EIO ); - goto retry; +spin_lock_bh (&ctx->pk_lock); +memcpy (xts_param.key + offset, + ctx->pk[0 ].protkey, keylen); +spin_unlock_bh (&ctx->pk_lock); } } +return ret; }
@@ -485,6 +545,7 @@ static int ctr_paes_init(struct crypto_skcipher *tfm)struct s390_paes_ctx *ctx =crypto_skcipher_ctx (tfm); ctx->kb.key =NULL ; +spin_lock_init (&ctx->pk_lock);return 0 ; }
@@ -496,11 +557,11 @@ static void ctr_paes_exit(struct crypto_skcipher *tfm)_free_kb_keybuf (&ctx->kb); } -static int __ctr_paes_set_key (struct s390_paes_ctx *ctx) +static inline int __ctr_paes_set_key (struct s390_paes_ctx *ctx) {unsigned long fc; -if (__paes_convert_key (&ctx->kb, &ctx->pk)) +if (__paes_convert_key (ctx))return -EINVAL ;/* Pick the correct function code based on the protected key type */
@@ -556,45 +617,61 @@ static int ctr_paes_crypt(struct skcipher_request *req)struct skcipher_walk walk;unsigned int nbytes, n, k;int ret, locked; - - locked =spin_trylock (&ctrblk_lock); +struct { +u8 key[MAXPROTKEYSIZE ]; + } param; ret =skcipher_walk_virt (&walk, req, false); +if (ret) +return ret; + +spin_lock_bh (&ctx->pk_lock); +memcpy (param.key, ctx->pk.protkey,MAXPROTKEYSIZE ); +spin_unlock_bh (&ctx->pk_lock); + + locked =mutex_trylock (&ctrblk_lock); +while ((nbytes = walk.nbytes) >=AES_BLOCK_SIZE ) { n =AES_BLOCK_SIZE ;if (nbytes >=2 *AES_BLOCK_SIZE && locked) n =__ctrblk_init (ctrblk, walk.iv, nbytes); ctrptr = (n >AES_BLOCK_SIZE ) ? ctrblk : walk.iv; - k =cpacf_kmctr (ctx->fc, ctx->pk.protkey, walk.dst.virt.addr, + k =cpacf_kmctr (ctx->fc, ¶m, walk.dst.virt.addr, walk.src.virt.addr, n, ctrptr);if (k) {if (ctrptr == ctrblk)memcpy (walk.iv, ctrptr + k -AES_BLOCK_SIZE ,AES_BLOCK_SIZE );crypto_inc (walk.iv,AES_BLOCK_SIZE ); - ret =skcipher_walk_done (&walk, nbytes - n); + ret =skcipher_walk_done (&walk, nbytes - k); }if (k < n) { -if (__ctr_paes_set_key (ctx) !=0 ) { +if (__paes_convert_key (ctx)) {if (locked) -spin_unlock (&ctrblk_lock); +mutex_unlock (&ctrblk_lock);return skcipher_walk_done (&walk, -EIO ); } +spin_lock_bh (&ctx->pk_lock); +memcpy (param.key, ctx->pk.protkey,MAXPROTKEYSIZE ); +spin_unlock_bh (&ctx->pk_lock); } }if (locked) -spin_unlock (&ctrblk_lock); +mutex_unlock (&ctrblk_lock);/* * final block may be < AES_BLOCK_SIZE, copy only nbytes */ if (nbytes) {while (1 ) { -if (cpacf_kmctr (ctx->fc, ctx->pk.protkey, buf, +if (cpacf_kmctr (ctx->fc, ¶m, buf, walk.src.virt.addr,AES_BLOCK_SIZE , walk.iv) ==AES_BLOCK_SIZE )break ; -if (__ctr_paes_set_key (ctx) !=0 ) +if (__paes_convert_key (ctx))return skcipher_walk_done (&walk, -EIO ); +spin_lock_bh (&ctx->pk_lock); +memcpy (param.key, ctx->pk.protkey,MAXPROTKEYSIZE ); +spin_unlock_bh (&ctx->pk_lock); }memcpy (walk.dst.virt.addr, buf, nbytes);crypto_inc (walk.iv,AES_BLOCK_SIZE );
@@ -674,14 +751,14 @@ static int __init paes_s390_init(void)if (cpacf_test_func (&kmctr_functions,CPACF_KMCTR_PAES_128 ) ||cpacf_test_func (&kmctr_functions,CPACF_KMCTR_PAES_192 ) ||cpacf_test_func (&kmctr_functions,CPACF_KMCTR_PAES_256 )) { - ret =crypto_register_skcipher (&ctr_paes_alg); -if (ret) - goto out_err; ctrblk = (u8 *)__get_free_page (GFP_KERNEL );if (!ctrblk) { ret = -ENOMEM ; goto out_err; } + ret =crypto_register_skcipher (&ctr_paes_alg); +if (ret) + goto out_err; }return 0 ;
Signature · 1 line
2.17.1
Herbert Xu
maintainerRe: [PATCH 2/3] s390/crypto: Rework on paes implementation
arch/s390/crypto/paes_s390.c static int ecb_paes_init(struct crypto_skcipher *tfm) · line 131
Quoted 6 lines · Harald Freudenberger
arch/s390/crypto/paes_s390.c +1
-0@@ -129,6 +128,7 @@ static int ecb_paes_init(struct crypto_skcipher *tfm)struct s390_paes_ctx *ctx =crypto_skcipher_ctx (tfm); ctx->kb.key =NULL ; +spin_lock_init (&ctx->pk_lock);
This makes no sense. The context is per-tfm, and each tfm should have a single key at any time. The synchronisation of setkey vs. crypto operations is left to the user of the tfm, not the implementor.
So why do you need this spin lock at all?
Cheers,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Harald Freudenberger
maintainerRe: [PATCH 2/3] s390/crypto: Rework on paes implementation
Quoted 11 lines · Herbert Xu
arch/s390/crypto/paes_s390.c static int ecb_paes_init(struct crypto_skcipher *tfm) · line 131
Quoted 5 lines · Harald Freudenberger
arch/s390/crypto/paes_s390.c +1
-0@@ -129,6 +128,7 @@ static int ecb_paes_init(struct crypto_skcipher *tfm)struct s390_paes_ctx *ctx =crypto_skcipher_ctx (tfm); ctx->kb.key =NULL ; +spin_lock_init (&ctx->pk_lock);This makes no sense. The context is per-tfm, and each tfm should have a single key at any time. The synchronisation of setkey vs. crypto operations is left to the user of the tfm, not the implementor.
Quoted 3 lines
So why do you need this spin lock at all?
Cheers,
The setkey() sets the base key material (usually a secure key) to an tfm instance. From this key a 'protected key' (pkey) is derived which may get invalid at any time and may need to get re-derived from the base key material.
An tfm instance may be shared, so the context where the pkey is stored into is also shared. So when a pkey gets invalid there is a need to update the pkey value within the context struct. This update needs to be done atomic as another thread may concurrently use this pkey value. That's all what this spinlock does. Make sure read and write operations on the pkey within the context are atomic.
It is still possible that two threads copy the pkey, try to use it, find out that it is invalid and needs refresh, re-derive and both update the pkey memory serialized by the spinlock. But this is no issue. The spinlock makes sure the stored pkey is always a consistent pkey (which may be valid or invalid but not corrupted).
Hope this makes it clear
Thanks
Herbert Xu
maintainerRe: [PATCH 2/3] s390/crypto: Rework on paes implementation
Quoted 7 lines · Harald Freudenberger
The
setkey()sets the base key material (usually a secure key) to an tfm instance. From this key a 'protected key' (pkey) is derived which may get invalid at any time and may need to get re-derived from the base key material.
An tfm instance may be shared, so the context where the pkey is stored into is also shared. So when a pkey gets invalid there is a need to update the pkey value within the context struct. This update needs
Quoted 8 lines
to be done atomic as another thread may concurrently use this pkey value. That's all what this spinlock does. Make sure read and write operations on the pkey within the context are atomic.
It is still possible that two threads copy the pkey, try to use it, find out that it is invalid and needs refresh, re-derive and both update the pkey memory serialized by the spinlock. But this is no issue. The spinlock makes sure the stored pkey is always a consistent pkey (which may be valid or invalid but not corrupted).
OK. Can you give me a bit more background info on how often this is likely to happen? I mean it happened every time you might as well not store the protected key in the tfm at all.
Thanks,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Harald Freudenberger
maintainerRe: [PATCH 2/3] s390/crypto: Rework on paes implementation
Quoted 16 lines · Herbert Xu
Quoted 7 lines · Harald Freudenberger
The
setkey()sets the base key material (usually a secure key) to an tfm instance. From this key a 'protected key' (pkey) is derived which may get invalid at any time and may need to get re-derived from the base key material.
An tfm instance may be shared, so the context where the pkey is stored into is also shared. So when a pkey gets invalid there is a need to update the pkey value within the context struct. This update needsQuoted 8 lines
to be done atomic as another thread may concurrently use this pkey value. That's all what this spinlock does. Make sure read and write operations on the pkey within the context are atomic.
It is still possible that two threads copy the pkey, try to use it, find out that it is invalid and needs refresh, re-derive and both update the pkey memory serialized by the spinlock. But this is no issue. The spinlock makes sure the stored pkey is always a consistent pkey (which may be valid or invalid but not corrupted).
Quoted 5 lines
OK. Can you give me a bit more background info on how often this is likely to happen? I mean it happened every time you might as well not store the protected key in the tfm at all.
Thanks,
The pkey is in fact a encrypted key + a verification pattern for the encrypted key used. It gets invalid when this encryption key changes. The encryption key changes when the LPAR is re-activated so for example on suspend/resume or an Linux running as kvm guest gets relocated. So this happens very rarely.
Herbert Xu
maintainerRe: [PATCH 2/3] s390/crypto: Rework on paes implementation
Quoted 6 lines · Harald Freudenberger
The pkey is in fact a encrypted key + a verification pattern for the encrypted key used. It gets invalid when this encryption key changes. The encryption key changes when the LPAR is re-activated so for example on suspend/resume or an Linux running as kvm guest gets relocated. So this happens very rarely.
I see. Is there any way of you finding out that the key has been invalidated apart from trying out the crypto and having it fail?
Ideally you'd have a global counter that gets incremented everytime an invalidation occurs. You can then regenerate your key if its generation counter differs from the current global counter.
Also when the crypto fails due to an invalid key you're currently calling skcipher_walk_done with zero. This is wrong as the done function must be called with a positive value or an error. In some cases this can cause a crash in scatterwalk.
IOW you should just repeat the crypto operation after regenerating the key rather than looping around again.
Cheers,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Harald Freudenberger
maintainerRe: [PATCH 2/3] s390/crypto: Rework on paes implementation
Quoted 8 lines · Herbert Xu
Quoted 5 lines · Harald Freudenberger
The pkey is in fact a encrypted key + a verification pattern for the encrypted key used. It gets invalid when this encryption key changes. The encryption key changes when the LPAR is re-activated so for example on suspend/resume or an Linux running as kvm guest gets relocated. So this happens very rarely.
I see. Is there any way of you finding out that the key has been invalidated apart from trying out the crypto and having it fail?
No. By using the pkey for a crypto operation the hardware checks the verification pattern and if there is a mismatch it simple rejects the operation. Theoretically such an operation can only partly complete and then a pkey could get invalid. I have no way to check if the pkey is still valid before the cpacf instruction call.
Quoted 5 lines
Ideally you'd have a global counter that gets incremented everytime an invalidation occurs. You can then regenerate your key if its generation counter differs from the current global counter.
Quoted 7 lines
Also when the crypto fails due to an invalid key you're currently calling
skcipher_walk_donewith zero. This is wrong as the done function must be called with a positive value or an error. In some cases this can cause a crash in scatterwalk.IOW you should just repeat the crypto operation after regenerating the key rather than looping around again.
That's right. I'll try to rework the functions this way to avoid calling skciper_walk_done with 0.
Thanks
Quoted 2 lines
Cheers,
Harald Freudenberger
maintainerPATCH 3/3 crypto/testmgr: add selftests for paes-s390
In reply to Harald FreudenbergerThis patch adds selftests for the s390 specific protected key AES (PAES) cipher implementations:
* cbc-paes-s390
* ctr-paes-s390
* ecb-paes-s390
* xts-paes-s390
PAES is an AES cipher but with encrypted ('protected') key material. So here come ordinary AES enciphered data values but with a special key format understood by the PAES implementation.
The testdata definitons and testlist entries are surrounded by #if IS_ENABLED(CONFIG_CRYPTO_PAES_S390) because they don't make any sense on non s390 platforms or without the PAES cipher implementation.
--- crypto/testmgr.c | 36 +++++ crypto/testmgr.h | 334 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 370 insertions(+)
crypto/testmgr.c +36 -0
@@ -4104,6 +4104,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(tf_cbc_tv_template) }, }, { +#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390) + .alg = "cbc-paes-s390", + .fips_allowed = 1, + .test = alg_test_skcipher, + .suite = { + .cipher = __VECS(paes_cbc_tv_template) + } + }, { +#endif .alg = "cbcmac(aes)", .fips_allowed = 1, .test = alg_test_hash,
@@ -4252,6 +4261,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(tf_ctr_tv_template) } }, { +#if IS_ENABLED (CONFIG_CRYPTO_PAES_S390 ) + .alg = "ctr-paes-s390", + .fips_allowed = 1, + .test = alg_test_skcipher, + .suite = { + .cipher = __VECS(paes_ctr_tv_template) + } + }, { +#endif .alg = "cts(cbc(aes))", .test = alg_test_skcipher, .fips_allowed = 1,
@@ -4538,6 +4556,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(xtea_tv_template) } }, { +#if IS_ENABLED (CONFIG_CRYPTO_PAES_S390 ) + .alg = "ecb-paes-s390", + .fips_allowed = 1, + .test = alg_test_skcipher, + .suite = { + .cipher = __VECS(paes_ecb_tv_template) + } + }, { +#endif .alg = "ecdh", .test = alg_test_kpp, .fips_allowed = 1,
@@ -5109,6 +5136,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(tf_xts_tv_template) } }, { +#if IS_ENABLED (CONFIG_CRYPTO_PAES_S390 ) + .alg = "xts-paes-s390", + .fips_allowed = 1, + .test = alg_test_skcipher, + .suite = { + .cipher = __VECS(paes_xts_tv_template) + } + }, { +#endif .alg = "xts4096(paes)", .test = alg_test_null, .fips_allowed = 1,
crypto/testmgr.h +334 -0
338 lines not on this page · raw message
Signature · 1 line
2.17.1
Herbert Xu
maintainerRe: [PATCH 3/3] crypto/testmgr: add selftests for paes-s390
Quoted 16 lines · Harald Freudenberger
This patch adds selftests for the s390 specific protected key AES (PAES) cipher implementations:
* cbc-paes-s390
* ctr-paes-s390
* ecb-paes-s390
* xts-paes-s390
PAES is an AES cipher but with encrypted ('protected') key material. So here come ordinary AES enciphered data values but with a special key format understood by the PAES implementation.The testdata definitons and testlist entries are surrounded by #if
IS_ENABLED(CONFIG_CRYPTO_PAES_S390)because they don't make any sense on non s390 platforms or without the PAES cipher implementation.
Quoted 5 lines
Signed-off-by Harald Freudenberger <[email protected]>--- crypto/testmgr.c | 36 +++++ crypto/testmgr.h | 334 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 370 insertions(+)
So with your cleartext work, I gather that you can now supply arbitrary keys to paes? If so my preferred method of testing it would be to add a paes-specific tester function that massaged the existing aes vectors into the format required by paes so you get exactly the same testing coverage as plain aes.
Is this possible?
Thanks,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Harald Freudenberger
maintainerRe: [PATCH 3/3] crypto/testmgr: add selftests for paes-s390
Quoted 28 lines · Herbert Xu
Quoted 16 lines · Harald Freudenberger
This patch adds selftests for the s390 specific protected key AES (PAES) cipher implementations:
* cbc-paes-s390
* ctr-paes-s390
* ecb-paes-s390
* xts-paes-s390
PAES is an AES cipher but with encrypted ('protected') key material. So here come ordinary AES enciphered data values but with a special key format understood by the PAES implementation.The testdata definitons and testlist entries are surrounded by #if
IS_ENABLED(CONFIG_CRYPTO_PAES_S390)because they don't make any sense on non s390 platforms or without the PAES cipher implementation.Quoted 5 lines
Signed-off-by Harald Freudenberger <[email protected]>--- crypto/testmgr.c | 36 +++++ crypto/testmgr.h | 334 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 370 insertions(+)So with your cleartext work, I gather that you can now supply arbitrary keys to paes? If so my preferred method of testing it would be to add a paes-specific tester function that massaged the existing aes vectors into the format required by paes so you get exactly the same testing coverage as plain aes.
Quoted 3 lines
Is this possible?
Thanks,
Thanks for your feedback.
I thought about this too. But it would require to implement own versions of alg_test_skcipher() and test_skcipher() and test_skcipher_vs_generic_impl() and that's a lot of complicated code unique for paes within testmgr.c I'd like to avoid.
Herbert Xu
maintainerRe: [PATCH 3/3] crypto/testmgr: add selftests for paes-s390
Quoted 5 lines · Harald Freudenberger
I thought about this too. But it would require to implement own versions of
alg_test_skcipher()andtest_skcipher()andtest_skcipher_vs_generic_impl()and that's a lot of complicated code unique for paes withintestmgr.cI'd like to avoid.
I don't think you have to do test_skcipher_vs_generic_impl right away. Just supporting the normal test vectors should be the same as your current patch with the advantage that any changes to the generic test vectors will be picked up automatically for paes.
Thanks,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 3/3] crypto/testmgr: add selftests for paes-s390
In reply to Herbert XuQuoted 28 lines · Herbert Xu
Quoted 16 lines · Harald Freudenberger
This patch adds selftests for the s390 specific protected key AES (PAES) cipher implementations:
* cbc-paes-s390
* ctr-paes-s390
* ecb-paes-s390
* xts-paes-s390
PAES is an AES cipher but with encrypted ('protected') key material. So here come ordinary AES enciphered data values but with a special key format understood by the PAES implementation.The testdata definitons and testlist entries are surrounded by #if
IS_ENABLED(CONFIG_CRYPTO_PAES_S390)because they don't make any sense on non s390 platforms or without the PAES cipher implementation.Quoted 5 lines
Signed-off-by Harald Freudenberger <[email protected]>--- crypto/testmgr.c | 36 +++++ crypto/testmgr.h | 334 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 370 insertions(+)So with your cleartext work, I gather that you can now supply arbitrary keys to paes? If so my preferred method of testing it would be to add a paes-specific tester function that massaged the existing aes vectors into the format required by paes so you get exactly the same testing coverage as plain aes.
Quoted 3 lines
Is this possible?
Thanks,
So here is now a reworked version of the paes selftest invocation within the testmanager code. I picked your suggestions and now the paes ciphers are able to deal with plain aes key values and so can benefit from the generic aes testcases.
Please note, this patch needs as a prerequirement some other patches which enable the base functionality in the zcyrpt device driver and the pkey kernel module. These patches will come with the next s390 subsystem merge for the 5.6 development kernel. If you agree to this patch, then Vasily will push this patch with the s390 subsystem together as part of the patch series.
Thanks and here is the patch for the testmanager:
============================================================
From fb82ea49910b8cde33ca7286c8855c0326e78177 Mon Sep 17 00:00:00 2001
From: Harald Freudenberger <[email protected]>
Date: Wed, 22 Jan 2020 14:43:23 +0100
Subject: [PATCH] crypto/testmgr: enable selftests for paes-s390 ciphers
This patch enables the selftests for the s390 specific protected key AES (PAES) cipher implementations:
* cbc-paes-s390
* ctr-paes-s390
* ecb-paes-s390
* xts-paes-s390
PAES is an AES cipher but with encrypted ('protected') key material. However, the paes ciphers are able to derive an protected key from clear key material with the help of the pkey kernel module.
So this patch now enables the generic AES tests for the paes ciphers. Under the hood the setkey() functions rearrange the clear key values as clear key token and so the pkey kernel module is able to provide protected key blobs from the given clear key values. The derived protected key blobs are then used within the paes cipers and should produce the very same results as the generic AES implementation with the clear key values.
The s390-paes cipher testlist entries are surrounded by #if IS_ENABLED(CONFIG_CRYPTO_PAES_S390) because they don't make any sense on non s390 platforms or without the PAES cipher implementation.
---
crypto/testmgr.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
crypto/testmgr.c +0 -0
@@ -4156,6 +4156,15 @@ static const struct alg_test_desc alg_test_descs[] = {
.cipher = __VECS(tf_cbc_tv_template)
},
}, {
+#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390)
+ .alg = "cbc-paes-s390",
+ .fips_allowed = 1,
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = __VECS(aes_cbc_tv_template)
+ }
+ }, {
+#endif
.alg = "cbcmac(aes)",
.fips_allowed = 1,
.test = alg_test_hash,
@@ -4304,6 +4313,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(tf_ctr_tv_template)
}
}, {
+#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390)
+ .alg = "ctr-paes-s390",
+ .fips_allowed = 1,
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = __VECS(aes_ctr_tv_template)
+ }
+ }, {
+#endif
.alg = "cts(cbc(aes))",
.test = alg_test_skcipher,
.fips_allowed = 1,
@@ -4596,6 +4614,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(xtea_tv_template)
}
}, {
+#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390)
+ .alg = "ecb-paes-s390",
+ .fips_allowed = 1,
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = __VECS(aes_tv_template)
+ }
+ }, {
+#endif
.alg = "ecdh",
.test = alg_test_kpp,
.fips_allowed = 1,
@@ -5167,6 +5194,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(tf_xts_tv_template)
}
}, {
+#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390)
+ .alg = "xts-paes-s390",
+ .fips_allowed = 1,
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = __VECS(aes_xts_tv_template)
+ }
+ }, {
+#endif
.alg = "xts4096(paes)",
.test = alg_test_null,
.fips_allowed = 1,
Signature · 1 line
2.17.1
Harald Freudenberger
maintainerRe: [PATCH 3/3] crypto/testmgr: add selftests for paes-s390
Hello Herbert
sorry for my pressing ... but I received questions from a distro about if they can pick this. And the pre requirement is to have this upstream accepted. So will you accept this and it will appear in the 5.6 kernel or do you want me to do some rework ?
Thanks
Quoted 149 lines · Harald Freudenberger
Quoted 28 lines · Herbert Xu
Quoted 16 lines · Harald Freudenberger
This patch adds selftests for the s390 specific protected key AES (PAES) cipher implementations:
* cbc-paes-s390
* ctr-paes-s390
* ecb-paes-s390
* xts-paes-s390
PAES is an AES cipher but with encrypted ('protected') key material. So here come ordinary AES enciphered data values but with a special key format understood by the PAES implementation.The testdata definitons and testlist entries are surrounded by #if
IS_ENABLED(CONFIG_CRYPTO_PAES_S390)because they don't make any sense on non s390 platforms or without the PAES cipher implementation.Quoted 5 lines
Signed-off-by Harald Freudenberger <[email protected]>--- crypto/testmgr.c | 36 +++++ crypto/testmgr.h | 334 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 370 insertions(+)So with your cleartext work, I gather that you can now supply arbitrary keys to paes? If so my preferred method of testing it would be to add a paes-specific tester function that massaged the existing aes vectors into the format required by paes so you get exactly the same testing coverage as plain aes.
Quoted 3 lines
Is this possible?
Thanks,
So here is now a reworked version of the paes selftest invocation within the testmanager code. I picked your suggestions and now the paes ciphers are able to deal with plain aes key values and so can benefit from the generic aes testcases.
Please note, this patch needs as a prerequirement some other patches which enable the base functionality in the zcyrpt device driver and the pkey kernel module. These patches will come with the next s390 subsystem merge for the 5.6 development kernel. If you agree to this patch, then Vasily will push this patch with the s390 subsystem together as part of the patch series.Thanks and here is the patch for the testmanager:
============================================================
From
fb82ea49910b8cde33ca7286c8855c0326e78177Mon Sep 17 00:00:00 2001
From: Harald Freudenberger <[email protected]>
Date: Wed, 22 Jan 2020 14:43:23 +0100
Subject: [PATCH]crypto/testmgr: enable selftests for paes-s390 ciphersThis patch enables the selftests for the s390 specific protected key AES (PAES) cipher implementations:
* cbc-paes-s390
* ctr-paes-s390
* ecb-paes-s390
* xts-paes-s390
PAES is an AES cipher but with encrypted ('protected') key material. However, the paes ciphers are able to derive an protected key from clear key material with the help of the pkey kernel module.So this patch now enables the generic AES tests for the paes ciphers. Under the hood the
setkey()functions rearrange the clear key values as clear key token and so the pkey kernel module is able to provide protected key blobs from the given clear key values. The derived protected key blobs are then used within the paes cipers and should produce the very same results as the generic AES implementation with the clear key values.The s390-paes cipher testlist entries are surrounded by #if
IS_ENABLED(CONFIG_CRYPTO_PAES_S390)because they don't make any sense on non s390 platforms or without the PAES cipher implementation.Signed-off-by Harald Freudenberger <[email protected]>Reviewed-by Ingo Franzki <[email protected]>Acked-by Vasily Gorbik <[email protected]>---
crypto/testmgr.c | 36 ++++++++++++++++++++++++++++++++++++1 file changed, 36 insertions(+)crypto/testmgr.c +36
-0@@ -4156,6 +4156,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(tf_cbc_tv_template) }, }, { +#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390) + .alg = "cbc-paes-s390", + .fips_allowed = 1, + .test = alg_test_skcipher, + .suite = { + .cipher = __VECS(aes_cbc_tv_template) + } + }, { +#endif .alg = "cbcmac(aes)", .fips_allowed = 1, .test = alg_test_hash,@@ -4304,6 +4313,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(tf_ctr_tv_template) } }, { +#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390) + .alg = "ctr-paes-s390", + .fips_allowed = 1, + .test = alg_test_skcipher, + .suite = { + .cipher = __VECS(aes_ctr_tv_template) + } + }, { +#endif .alg = "cts(cbc(aes))", .test = alg_test_skcipher, .fips_allowed = 1,@@ -4596,6 +4614,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(xtea_tv_template) } }, { +#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390) + .alg = "ecb-paes-s390", + .fips_allowed = 1, + .test = alg_test_skcipher, + .suite = { + .cipher = __VECS(aes_tv_template) + } + }, { +#endif .alg = "ecdh", .test = alg_test_kpp, .fips_allowed = 1,@@ -5167,6 +5194,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(tf_xts_tv_template) } }, { +#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390) + .alg = "xts-paes-s390", + .fips_allowed = 1, + .test = alg_test_skcipher, + .suite = { + .cipher = __VECS(aes_xts_tv_template) + } + }, { +#endif .alg = "xts4096(paes)", .test = alg_test_null, .fips_allowed = 1,
Herbert Xu
maintainerRe: [PATCH 3/3] crypto/testmgr: add selftests for paes-s390
Quoted 5 lines · Harald Freudenberger
Hello Herbert
sorry for my pressing ... but I received questions from a distro about if they can pick this. And the pre requirement is to have this upstream accepted. So will you accept this and it will appear in the 5.6 kernel or do you want me to do some rework ?
Hi Harald:
It's too late for 5.6 I'm afraid. However, if you can get them submitted right away then 5.7 is certainly not a problem.
Thanks,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Harald Freudenberger
maintainerPATCH 1/1 crypto/testmgr: add selftests for paes-s390
In reply to Harald FreudenbergerThis patch enables the selftests for the s390 specific protected key AES (PAES) cipher implementations:
* cbc-paes-s390
* ctr-paes-s390
* ecb-paes-s390
* xts-paes-s390
PAES is an AES cipher but with encrypted ('protected') key material. However, the paes ciphers are able to derive an protected key from clear key material with the help of the pkey kernel module.
So this patch now enables the generic AES tests for the paes ciphers. Under the hood the setkey() functions rearrange the clear key values as clear key token and so the pkey kernel module is able to provide protected key blobs from the given clear key values. The derived protected key blobs are then used within the paes cipers and should produce the very same results as the generic AES implementation with the clear key values.
The s390-paes cipher testlist entries are surrounded by #if IS_ENABLED(CONFIG_CRYPTO_PAES_S390) because they don't make any sense on non s390 platforms or without the PAES cipher implementation.
---
crypto/testmgr.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
crypto/testmgr.c +0 -0
@@ -4156,6 +4156,15 @@ static const struct alg_test_desc alg_test_descs[] = {
.cipher = __VECS(tf_cbc_tv_template)
},
}, {
+#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390)
+ .alg = "cbc-paes-s390",
+ .fips_allowed = 1,
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = __VECS(aes_cbc_tv_template)
+ }
+ }, {
+#endif
.alg = "cbcmac(aes)",
.fips_allowed = 1,
.test = alg_test_hash,
@@ -4304,6 +4313,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(tf_ctr_tv_template)
}
}, {
+#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390)
+ .alg = "ctr-paes-s390",
+ .fips_allowed = 1,
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = __VECS(aes_ctr_tv_template)
+ }
+ }, {
+#endif
.alg = "cts(cbc(aes))",
.test = alg_test_skcipher,
.fips_allowed = 1,
@@ -4596,6 +4614,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(xtea_tv_template)
}
}, {
+#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390)
+ .alg = "ecb-paes-s390",
+ .fips_allowed = 1,
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = __VECS(aes_tv_template)
+ }
+ }, {
+#endif
.alg = "ecdh",
.test = alg_test_kpp,
.fips_allowed = 1,
@@ -5167,6 +5194,15 @@ static const struct alg_test_desc alg_test_descs[] = { .cipher = __VECS(tf_xts_tv_template)
}
}, {
+#if IS_ENABLED(CONFIG_CRYPTO_PAES_S390)
+ .alg = "xts-paes-s390",
+ .fips_allowed = 1,
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = __VECS(aes_xts_tv_template)
+ }
+ }, {
+#endif
.alg = "xts4096(paes)",
.test = alg_test_null,
.fips_allowed = 1,
Signature · 1 line
2.17.1
Re: [PATCH] crypto/testmgr: add selftests for paes-s390
Quoted 23 lines · Harald Freudenberger
This patch enables the selftests for the s390 specific protected key AES (PAES) cipher implementations:
* cbc-paes-s390
* ctr-paes-s390
* ecb-paes-s390
* xts-paes-s390
PAES is an AES cipher but with encrypted ('protected') key material. However, the paes ciphers are able to derive an protected key from clear key material with the help of the pkey kernel module.So this patch now enables the generic AES tests for the paes ciphers. Under the hood the
setkey()functions rearrange the clear key values as clear key token and so the pkey kernel module is able to provide protected key blobs from the given clear key values. The derived protected key blobs are then used within the paes cipers and should produce the very same results as the generic AES implementation with the clear key values.The s390-paes cipher testlist entries are surrounded by #if
IS_ENABLED(CONFIG_CRYPTO_PAES_S390)because they don't make any sense on non s390 platforms or without the PAES cipher implementation.
Quoted 5 lines
Signed-off-by Harald Freudenberger <[email protected]>Signed-off-by Vasily Gorbik <[email protected]>---
crypto/testmgr.c | 36 ++++++++++++++++++++++++++++++++++++1 file changed, 36 insertions(+)
Thanks,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt