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

[Thomas Huth <thuth@redhat.com>]

On 27/05/2025 09.31, Harald Freudenberger wrote:
> 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.

I guess it's working for you since you have the "CONFIG_CRYPTO_DEV_VIRTIO=m" 
from the defconfig, and CRYPTO_DEV_VIRTIO selects CRYPTO_ENGINE.

I'm using a config without CONFIG_CRYPTO_DEV_VIRTIO, so maybe try to disable 
that in your .config, too, to see what happens...

  Thomas