Re: [PATCH v2] s390/ap: Support new APMLM field with PQAP/TAPQ instruction

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] s390/ap: order-8 kmalloc allocation causes DoS for crypto requests
--

commit c12ee44fe3064032047e06539777b0c95c7b1201
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/ap: Support new APMLM field with PQAP/TAPQ instruction

This commit adds support for the new AP message limit multiplier field in the
GR2 register for the PQAP instruction. It updates the HWINFO mask and
modifies the formula used to calculate the AP maximum message limit.

> diff --git a/drivers/s390/crypto/ap_card.c b/drivers/s390/crypto/ap_card.c
> --- a/drivers/s390/crypto/ap_card.c
> +++ b/drivers/s390/crypto/ap_card.c
> @@ -242,7 +242,8 @@ struct ap_card *ap_card_create(int id, struct ap_tapq_hwinfo hwinfo,
>  	ac->hwinfo = hwinfo;
>  	ac->id = id;
>  	ac->maxmsgsize = hwinfo.ml > 3 ?
> -		hwinfo.ml * AP_TAPQ_ML_FIELD_CHUNK_SIZE : AP_DEFAULT_MAX_MSG_SIZE;
> +		hwinfo.ml * (hwinfo.mlm + 1) * AP_TAPQ_ML_FIELD_CHUNK_SIZE :
> +		AP_DEFAULT_MAX_MSG_SIZE;

[Severity: High]
Will this scaling of the maximum message size cause order-8 physically
contiguous memory allocation failures?

By introducing the hwinfo.mlm multiplier, the maximum message size can now
scale up to around 960KB. This value is used to set the global maximum message
size.

However, looking at how messages are allocated in
drivers/s390/crypto/ap_bus.c in ap_init_apmsg():

void ap_init_apmsg(...)
{
        ...
        maxmsgsize = atomic_read(&ap_max_msg_size);
        ap_msg->msg = kmalloc(maxmsgsize, GFP_KERNEL);
        ...
}

And similarly in drivers/s390/crypto/zcrypt_queue.c in zcrypt_queue_alloc():

        zq->reply.msg = kmalloc(reply_buf_size, GFP_KERNEL);

Since these functions unconditionally use kmalloc() for the maximum size,
user-space crypto requests will trigger massive order-8 allocations. On a
system with fragmented memory, these physically contiguous allocations are
highly likely to fail. This could lead to a reliable denial of service for
hardware cryptographic services since the underlying AP instruction operates
on absolute memory addresses requiring physically contiguous memory.

Is there a plan to adjust the allocation strategy alongside this limit
increase, or otherwise cap the unconditional allocation sizes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261006145823.8421-1-freude@linux.ibm.com?part=1