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

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

[Harald Freudenberger]

There is a new field APMLM (AP message limit multiplier) defined
within the GR2 register on successful invocation of the TAPQ
subfunction for the PQAP instruction.

So the new formula to calculate the AP max message limit is now:

  if ml field <= 3
    AP max message limit is 12KB
  else
    AP max message limit = apml * (apmlm + 1) * 4KB

Also adapt the HWINFO mask to have this new apmlm field shine
through this bit filter mask.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
---
 arch/s390/include/asm/ap.h    | 4 ++--
 drivers/s390/crypto/ap_bus.h  | 2 +-
 drivers/s390/crypto/ap_card.c | 3 ++-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
index c91b6ace199d..01d575c35887 100644
--- a/arch/s390/include/asm/ap.h
+++ b/arch/s390/include/asm/ap.h
@@ -123,8 +123,8 @@ struct ap_tapq_hwinfo {
 			unsigned int	   : 14;
 			unsigned int at	   :  8; /* ap type */
 			unsigned int nd	   :  8; /* nr of domains */
-			unsigned int	   :  4;
-			unsigned int ml	   :  4; /* apxl ml */
+			unsigned int mlm   :  4; /* AP msg limit multiplier */
+			unsigned int ml	   :  4; /* AP msg limit */
 			unsigned int	   :  3;
 			unsigned int qd	   :  5; /* queue depth */
 		};
diff --git a/drivers/s390/crypto/ap_bus.h b/drivers/s390/crypto/ap_bus.h
index fb4d678336e4..34f9dcd96bc7 100644
--- a/drivers/s390/crypto/ap_bus.h
+++ b/drivers/s390/crypto/ap_bus.h
@@ -181,7 +181,7 @@ struct ap_card {
 	bool chkstop;			/* checkstop state */
 };
 
-#define TAPQ_CARD_HWINFO_MASK 0xFFFF0000FFFF0F1FUL
+#define TAPQ_CARD_HWINFO_MASK 0xFFFF0000FFFFFF1FUL
 #define ASSOC_IDX_INVALID 0x10000
 
 #define to_ap_card(x) container_of((x), struct ap_card, ap_dev.device)
diff --git a/drivers/s390/crypto/ap_card.c b/drivers/s390/crypto/ap_card.c
index c86397f4ddcd..e9a8180f08c2 100644
--- 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;
 
 	return ac;
 }
-- 
2.43.0

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

[sashiko-bot]

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

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

[Harald Freudenberger]

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 ?

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

[Finn Callies]

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)

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

[Finn Callies]

On 06.10.26 16:58, Harald Freudenberger wrote:
> There is a new field APMLM (AP message limit multiplier) defined
> within the GR2 register on successful invocation of the TAPQ
> subfunction for the PQAP instruction.
> 
> So the new formula to calculate the AP max message limit is now:
> 
>    if ml field <= 3
>      AP max message limit is 12KB
>    else
>      AP max message limit = apml * (apmlm + 1) * 4KB

As per architecture it is more like:

if apml < 3 && apmlm == 0
	mapml = 12k
else if apmlm == 0
	mapml = apml * 4k
else if apml > 0
	mapml = apml * (apmlm + 1) * 4k
else
	// undefined

But yours is effectively the same.

> 
> Also adapt the HWINFO mask to have this new apmlm field shine
> through this bit filter mask.
> 
> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
> ---
>   arch/s390/include/asm/ap.h    | 4 ++--
>   drivers/s390/crypto/ap_bus.h  | 2 +-
>   drivers/s390/crypto/ap_card.c | 3 ++-
>   3 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
> index c91b6ace199d..01d575c35887 100644
> --- a/arch/s390/include/asm/ap.h
> +++ b/arch/s390/include/asm/ap.h
> @@ -123,8 +123,8 @@ struct ap_tapq_hwinfo {
>   			unsigned int	   : 14;
>   			unsigned int at	   :  8; /* ap type */
>   			unsigned int nd	   :  8; /* nr of domains */
> -			unsigned int	   :  4;
> -			unsigned int ml	   :  4; /* apxl ml */
> +			unsigned int mlm   :  4; /* AP msg limit multiplier */
> +			unsigned int ml	   :  4; /* AP msg limit */
>   			unsigned int	   :  3;
>   			unsigned int qd	   :  5; /* queue depth */
>   		};
> diff --git a/drivers/s390/crypto/ap_bus.h b/drivers/s390/crypto/ap_bus.h
> index fb4d678336e4..34f9dcd96bc7 100644
> --- a/drivers/s390/crypto/ap_bus.h
> +++ b/drivers/s390/crypto/ap_bus.h
> @@ -181,7 +181,7 @@ struct ap_card {
>   	bool chkstop;			/* checkstop state */
>   };
>   
> -#define TAPQ_CARD_HWINFO_MASK 0xFFFF0000FFFF0F1FUL
> +#define TAPQ_CARD_HWINFO_MASK 0xFFFF0000FFFFFF1FUL
>   #define ASSOC_IDX_INVALID 0x10000
>   
>   #define to_ap_card(x) container_of((x), struct ap_card, ap_dev.device)
> diff --git a/drivers/s390/crypto/ap_card.c b/drivers/s390/crypto/ap_card.c
> index c86397f4ddcd..e9a8180f08c2 100644
> --- 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;
>   
>   	return ac;
>   }

Reviewed-by: Finn Callies <fcallies@linux.ibm.com>

Have you tested it with your qemu support or my mocking?

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

[Harald Freudenberger]

On 2026-10-07 16:05, Finn Callies wrote:
> On 06.10.26 16:58, Harald Freudenberger wrote:
>> There is a new field APMLM (AP message limit multiplier) defined
>> within the GR2 register on successful invocation of the TAPQ
>> subfunction for the PQAP instruction.
>> 
>> So the new formula to calculate the AP max message limit is now:
>> 
>>    if ml field <= 3
>>      AP max message limit is 12KB
>>    else
>>      AP max message limit = apml * (apmlm + 1) * 4KB
> 
> As per architecture it is more like:
> 
> if apml < 3 && apmlm == 0
> 	mapml = 12k
> else if apmlm == 0
> 	mapml = apml * 4k
this
> else if apml > 0
> 	mapml = apml * (apmlm + 1) * 4k
and this come to the same result.
And for ampl == 3 the formula results in 12KB,
> else
> 	// undefined
and this else is unreachable.
> 
> But yours is effectively the same.
Yep
> 
>> 
>> Also adapt the HWINFO mask to have this new apmlm field shine
>> through this bit filter mask.
>> 
>> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
>> ---
>>   arch/s390/include/asm/ap.h    | 4 ++--
>>   drivers/s390/crypto/ap_bus.h  | 2 +-
>>   drivers/s390/crypto/ap_card.c | 3 ++-
>>   3 files changed, 5 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
>> index c91b6ace199d..01d575c35887 100644
>> --- a/arch/s390/include/asm/ap.h
>> +++ b/arch/s390/include/asm/ap.h
>> @@ -123,8 +123,8 @@ struct ap_tapq_hwinfo {
>>   			unsigned int	   : 14;
>>   			unsigned int at	   :  8; /* ap type */
>>   			unsigned int nd	   :  8; /* nr of domains */
>> -			unsigned int	   :  4;
>> -			unsigned int ml	   :  4; /* apxl ml */
>> +			unsigned int mlm   :  4; /* AP msg limit multiplier */
>> +			unsigned int ml	   :  4; /* AP msg limit */
>>   			unsigned int	   :  3;
>>   			unsigned int qd	   :  5; /* queue depth */
>>   		};
>> diff --git a/drivers/s390/crypto/ap_bus.h 
>> b/drivers/s390/crypto/ap_bus.h
>> index fb4d678336e4..34f9dcd96bc7 100644
>> --- a/drivers/s390/crypto/ap_bus.h
>> +++ b/drivers/s390/crypto/ap_bus.h
>> @@ -181,7 +181,7 @@ struct ap_card {
>>   	bool chkstop;			/* checkstop state */
>>   };
>>   -#define TAPQ_CARD_HWINFO_MASK 0xFFFF0000FFFF0F1FUL
>> +#define TAPQ_CARD_HWINFO_MASK 0xFFFF0000FFFFFF1FUL
>>   #define ASSOC_IDX_INVALID 0x10000
>>     #define to_ap_card(x) container_of((x), struct ap_card, 
>> ap_dev.device)
>> diff --git a/drivers/s390/crypto/ap_card.c 
>> b/drivers/s390/crypto/ap_card.c
>> index c86397f4ddcd..e9a8180f08c2 100644
>> --- 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;
>>     	return ac;
>>   }
> 
> Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
> 
> Have you tested it with your qemu support or my mocking?

Still untested. I am about to test this in my qemu AP emulation soon.