New s390 specific protected key hmac
Subsystems (3)
Harald Freudenberger
maintainerv5 cover New s390 specific protected key hmac
Add support for protected key hmac ("phmac") for s390 arch.
With the latest machine generation there is now support for protected key (that is a key wrapped by a master key stored in firmware) hmac for sha2 (sha224, sha256, sha384 and sha512) for the s390 specific CPACF instruction kmac.
This patch adds support via 4 new shashes registered as phmac(sha224), phmac(sha256), phmac(sha384) and phmac(sha512).
Please note that as of now, there is no selftest enabled for these shashes, but the implementation has been tested with testcases via AF_ALG interface. However, there may come an improvement soon to use the available clear key hmac selftests.
Changelog:
v1: Initial version
v2: Increase HASH_MAX_DESCSIZE generic (not just for arch s390).
Fix one finding to use kmemdup instead of kmalloc/memcpy from test robot. Remove unneeded cpacf subfunctions checks. Simplify clone_tfm() function. Rebased to s390/features.
v3: Feedback from Herbert: Use GFP_ATOMIC in setkey function.
Feedback from Holger: rework tfm clone function, move convert key invocation from setkey to init function. Rebased to updated s390/features from 11/7/2024. Ready for integration if there are no complains on v3.
v4: Rewind back more or less to v2. Add code to check for non-sleeping
context. Non-sleeping context during attempt to derive the protected key from raw key material is not accepted and -EOPNOTSUPP is returned (also currently all derivation pathes would in fact never sleep). In general the phmac implementation is not to be used within non-sleeping context and the code header mentions this. Tested with (patched) dm-integrity - works fine.
v5: As suggested by Herbert now the shashes have been marked as
'internal' and wrapped by ahashes which use the cryptd if an atomic context is detected. So the visible phmac algorithms are now ahashes. Unfortunately the dm-integrity implementation currently requests and deals only with shashes and this phmac implementation is not fitting to the original goal any more...
Harald Freudenberger (1):
s390/crypto: New s390 specific protected key hash phmac
Holger Dengler (2):
crypto: api - Adjust HASH_MAX_DESCSIZE for s390-phmac context s390/crypto: Add protected key hmac subfunctions for KMAC
arch/s390/configs/debug_defconfig | 1 + arch/s390/configs/defconfig | 1 + arch/s390/crypto/Makefile | 1 + arch/s390/crypto/phmac_s390.c | 661 ++++++++++++++++++++++++++++++ arch/s390/include/asm/cpacf.h | 4 + drivers/crypto/Kconfig | 12 + include/crypto/hash.h | 5 +- 7 files changed, 682 insertions(+), 3 deletions(-) create mode 100644 arch/s390/crypto/phmac_s390.c
base-commit: 3f020399e4f1c690ce87b4c472f75b1fc89e07d5 --
2.43.0
Harald Freudenberger
maintainerPATCH v5 1/3 crypto: api - Adjust HASH_MAX_DESCSIZE for s390-phmac context
From: Holger Dengler <[email protected]>
The phmac context exceeds the generic "worst case". Change this define to cover the s390 specific 'phmac(sha512)' which is a "protected" key hmac-sha2 implementation.
--- include/crypto/hash.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
include/crypto/hash.h +2 -3
@@ -159,10 +159,9 @@ struct shash_desc {#define HASH_MAX_DIGESTSIZE 64/* -* Worst case is hmac(sha3-224-generic). Its context is a nested 'shash_desc' -* containing a 'struct sha3_state'. +* The max case is currently the s390 specific shash 'phmac(sha512)'. */ -#define HASH_MAX_DESCSIZE (sizeof(struct shash_desc) + 360) +#define HASH_MAX_DESCSIZE (sizeof(struct shash_desc) + 376)#define SHASH_DESC_ON_STACK (shash, ctx) \ char __##shash##_desc[sizeof(struct shash_desc) + HASH_MAX_DESCSIZE] \
Signature · 1 line
2.43.0
Harald Freudenberger
maintainerPATCH v5 2/3 s390/crypto: Add protected key hmac subfunctions for KMAC
In reply to Harald FreudenbergerFrom: Holger Dengler <[email protected]>
The CPACF KMAC instruction supports new subfunctions for protected key hmac. Add defines for these 4 new subfuctions.
--- arch/s390/include/asm/cpacf.h | 4 ++++ 1 file changed, 4 insertions(+)
arch/s390/include/asm/cpacf.h +4 -0
@@ -129,6 +129,10 @@#define CPACF_KMAC_HMAC_SHA_256 0x71#define CPACF_KMAC_HMAC_SHA_384 0x72#define CPACF_KMAC_HMAC_SHA_512 0x73 +#define CPACF_KMAC_PHMAC_SHA_224 0x78 +#define CPACF_KMAC_PHMAC_SHA_256 0x79 +#define CPACF_KMAC_PHMAC_SHA_384 0x7a +#define CPACF_KMAC_PHMAC_SHA_512 0x7b/* * Function codes for the PCKMO (PERFORM CRYPTOGRAPHIC KEY MANAGEMENT)
Signature · 1 line
2.43.0
Harald Freudenberger
maintainerPATCH v5 3/3 s390/crypto: New s390 specific protected key hash phmac
In reply to Harald FreudenbergerAdd support for protected key hmac ("phmac") for s390 arch.
With the latest machine generation there is now support for protected key (that is a key wrapped by a master key stored in firmware) hmac for sha2 (sha224, sha256, sha384 and sha512) for the s390 specific CPACF instruction kmac.
This patch adds support via 4 new ahashes registered as phmac(sha224), phmac(sha256), phmac(sha384) and phmac(sha512). Under the hood there are also 4 shashes marked as internal registered which are used by the ahashes either directly or via cryptd (in case of atomic context).
Please note that as of now, there is no selftest enabled for these hashes, but the implementation has been tested with testcases via AF_ALG interface.
--- arch/s390/configs/debug_defconfig | 1 + arch/s390/configs/defconfig | 1 + arch/s390/crypto/Makefile | 1 + arch/s390/crypto/phmac_s390.c | 661 ++++++++++++++++++++++++++++++ drivers/crypto/Kconfig | 12 + 5 files changed, 676 insertions(+) create mode 100644 arch/s390/crypto/phmac_s390.c
arch/s390/configs/debug_defconfig +1 -0
@@ -813,6 +813,7 @@ CONFIG_PKEY_EP11=m CONFIG_PKEY_PCKMO=m CONFIG_PKEY_UV=m CONFIG_CRYPTO_PAES_S390=m +CONFIG_CRYPTO_PHMAC_S390=m CONFIG_CRYPTO_DEV_VIRTIO=m CONFIG_SYSTEM_BLACKLIST_KEYRING=y CONFIG_CORDIC=m
arch/s390/configs/defconfig +1 -0
@@ -800,6 +800,7 @@ CONFIG_PKEY_EP11=m CONFIG_PKEY_PCKMO=m CONFIG_PKEY_UV=m CONFIG_CRYPTO_PAES_S390=m +CONFIG_CRYPTO_PHMAC_S390=m CONFIG_CRYPTO_DEV_VIRTIO=m CONFIG_SYSTEM_BLACKLIST_KEYRING=y CONFIG_CORDIC=m
arch/s390/crypto/Makefile +1 -0
@@ -16,6 +16,7 @@ obj-$(CONFIG_S390_PRNG) += prng.o obj-$(CONFIG_CRYPTO_GHASH_S390) += ghash_s390.o obj-$(CONFIG_CRYPTO_CRC32_S390) += crc32-vx_s390.o obj-$(CONFIG_CRYPTO_HMAC_S390) += hmac_s390.o +obj-$(CONFIG_CRYPTO_PHMAC_S390) += phmac_s390.o obj-y += arch_random.o crc32-vx_s390-y := crc32-vx.o crc32le-vx.o crc32be-vx.o
arch/s390/crypto/phmac_s390.c new file +661 -0
661 lines not on this page · raw message
drivers/crypto/Kconfig +12 -0
@@ -187,6 +187,18 @@ config CRYPTO_PAES_S390 Select this option if you want to use the paes cipher for example to use protected key encrypted devices. +config CRYPTO_PHMAC_S390 + tristate "PHMAC cipher algorithms" + depends on S390 + depends on PKEY + select CRYPTO_HASH + help + This is the s390 hardware accelerated implementation of the + protected key HMAC support for SHA224, SHA256, SHA384 and SHA512. + + Select this option if you want to use the phmac digests + for example to use dm-integrity with secure/protected keys. + config S390_PRNG tristate "Pseudo random number generator device driver" depends on S390
Signature · 1 line
2.43.0
Herbert Xu
maintainerRe: [PATCH v5 3/3] s390/crypto: New s390 specific protected key hash phmac
arch/s390/crypto/phmac_s390.c line 129
Quoted 10 lines · Harald Freudenberger
arch/s390/crypto/phmac_s390.c new file +9
-0+static inline int phmac_keyblob2pkey (const u8 *key,unsigned int keylen, +struct phmac_protkey *pk) +{ +int i, rc = -EIO ; + +/* try three times in case of busy card */ +for (i =0 ; rc && i <3 ; i++) { +if (rc == -EBUSY &&msleep_interruptible (1000 )) +return -EINTR ;
You can't sleep in crypto calls in general.
Now there are specific circumstances where sleeping is allowed, e.g., when the MAY_SLEEP flag is set, but I don't think this will be acceptable for your purpose.
I see the same problem exists in paes_s390, which was not reviewed on linux-crypto.
So what exactly causes the EBUSY? The 3 retries followed by failure seem rather dangerous too given that this could be used by the block layer for critical data that cannot fail.
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 v5 3/3] s390/crypto: New s390 specific protected key hash phmac
Quoted 19 lines · Herbert Xu
arch/s390/crypto/phmac_s390.c line 129
Quoted 11 lines · Harald Freudenberger
+static inline int phmac_keyblob2pkey(const u8 *key, unsigned int keylen,
arch/s390/crypto/phmac_s390.c new file +8
-0+ struct phmac_protkey *pk) +{ +int i, rc = -EIO ; + +/* try three times in case of busy card */ +for (i =0 ; rc && i <3 ; i++) { +if (rc == -EBUSY &&msleep_interruptible (1000 )) +return -EINTR ;You can't sleep in crypto calls in general.
Now there are specific circumstances where sleeping is allowed, e.g., when the
MAY_SLEEPflag is set, but I don't think this will be acceptable for your purpose.
Quoted 8 lines
I see the same problem exists in
paes_s390, which was not reviewed on linux-crypto.So what exactly causes the EBUSY? The 3 retries followed by failure seem rather dangerous too given that this could be used by the block layer for critical data that cannot fail.
Cheers,
Well, I fear the paes implementation is similar broken. The EBUSY is a reaction of the zcrpyt/AP bus when no eligible crypto card has been found and a ansynchronous bus scan is running. In that case the caller should retry in the hope that the bus scan detects a eligible card. Please note that the sleep only happens in in_task() context for the paes implementation.
For the phmac implementation - didn't you suggest to wrap this with an asynchronous hmac to be able to sleep in the wrapped synchronous hmac?
Herbert Xu
maintainerRe: [PATCH v5 3/3] s390/crypto: New s390 specific protected key hash phmac
Quoted 5 lines · Harald Freudenberger
Well, I fear the paes implementation is similar broken. The EBUSY is a reaction of the zcrpyt/AP bus when no eligible crypto card has been found and a ansynchronous bus scan is running. In that case the caller should retry in the hope that the bus scan detects a eligible card.
So this is a rare event, right? Can we expect this to eventually succeed? Or are there situations where this can legitimately fail?
Quoted 2 lines
Please note that the sleep only happens in
in_task()context for the paes implementation.
That's still broken. There are situations where in_task() is true but you can't sleep, e.g., spin locks held without preemption.
In general, you cannot determine whether you can sleep safely. That's why we rely on the user to tell us whether we can sleep or not.
Quoted 2 lines
For the phmac implementation - didn't you suggest to wrap this with an asynchronous hmac to be able to sleep in the wrapped synchronous hmac?
I don't think this is a viable strategy since these are not short sleeps.
I think you're better off making both paes and phmac async. However, they can remain synchronous in practice until you actually need to sleep.
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