Re: [PATCH v5 2/2] s390/crypto: Rework protected key AES for true asynch support

[Harald Freudenberger <freude@linux.ibm.com>]

On 2025-05-26 17:25, Thomas Huth wrote:
> On 14/05/2025 11.09, Harald Freudenberger wrote:
>> This is a complete rework of the protected key AES (PAES) 
>> implementation.
>> The goal of this rework is to implement the 4 modes (ecb, cbc, ctr, 
>> xts)
>> in a real asynchronous fashion:
>> - init(), exit() and setkey() are synchronous and don't allocate any
>>    memory.
>> - the encrypt/decrypt functions first try to do the job in a 
>> synchronous
>>    manner. If this fails, for example the protected key got invalid 
>> caused
>>    by a guest suspend/resume or guest migration action, the 
>> encrypt/decrypt
>>    is transferred to an instance of the crypto engine (see below) for
>>    asynchronous processing.
>>    These postponed requests are then handled by the crypto engine by
>>    invoking the do_one_request() callback but may of course again run 
>> into
>>    a still not converted key or the key is getting invalid. If the key 
>> is
>>    still not converted, the first thread does the conversion and 
>> updates
>>    the key status in the transformation context. The conversion is
>>    invoked via pkey API with a new flag PKEY_XFLAG_NOMEMALLOC.
>>    Note that once there is an active requests enqueued to get async
>>    processed via crypto engine, further requests also need to go via
>>    crypto engine to keep the request sequence.
>> 
>> This patch together with the pkey/zcrypt/AP extensions to support
>> the new PKEY_XFLAG_NOMEMMALOC should toughen the paes crypto 
>> algorithms
>> to truly meet the requirements for in-kernel skcipher implementations
>> and the usage patterns for the dm-crypt and dm-integrity layers.
>> 
>> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
>> Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
>> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
>> ---
>>   arch/s390/crypto/paes_s390.c | 1812 
>> ++++++++++++++++++++++++----------
>>   1 file changed, 1270 insertions(+), 542 deletions(-)
> 
>  Hi Harald,
> 
> I'm currently facing these errors when building linux-next:
> 
> ERROR: modpost: "crypto_engine_stop" [arch/s390/crypto/paes_s390.ko] 
> undefined!
> ERROR: modpost: "crypto_engine_exit" [arch/s390/crypto/paes_s390.ko] 
> undefined!
> ERROR: modpost: "crypto_engine_unregister_skcipher"
> [arch/s390/crypto/paes_s390.ko] undefined!
> ERROR: modpost: "crypto_engine_alloc_init_and_set"
> [arch/s390/crypto/paes_s390.ko] undefined!
> ERROR: modpost: "crypto_engine_start" [arch/s390/crypto/paes_s390.ko] 
> undefined!
> ERROR: modpost: "crypto_engine_register_skcipher"
> [arch/s390/crypto/paes_s390.ko] undefined!
> ERROR: modpost: "crypto_finalize_skcipher_request"
> [arch/s390/crypto/paes_s390.ko] undefined!
> ERROR: modpost: "crypto_transfer_skcipher_request_to_engine"
> [arch/s390/crypto/paes_s390.ko] undefined!
> 
> I think the Kconfig is missing a "select CRYPTO_ENGINE" somewhere?
> 
>  Thomas

Well, with the rework the paes_s390 module has a dependency to the
crypto engine which is the kernel module "crypto_engine". There is
a kernel config CONFIG_CRYPTO_ENGINE but this is not defined in our
defconfig and debug_defconfig. However, when I build a defconfig
kernel I automatically get CONFIG_CRYPTO_ENGINE=m in my .config.

However, I'll check if there is a
SELECT CRYPTO_ENGINE
needed in the paes entry in drivers/crypto/Kconfig

Thanks for this hint