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

[Finn Callies <fcallies@linux.ibm.com>]

On 06.10.26 17:53, Harald Freudenberger wrote:
> On 2026-10-06 17:09, sashiko-bot@kernel.org wrote:
>> 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?
> 
> Hm this leads to the question if there should be an upper limit for this
> AP max message size. However this is then a protection against malicious
> firmware as the both fields ml and mlm are provided via TAPQ from firmware.
> 
> @Holger, @Finn any suggestions ?

I think when firmware is compromised this is not our biggest problem...
We could add a maximum valid apml which is whatever the firmware reports 
for the most current card generation. (Currently 24k)