Re: [PATCH net-next v6 10/19] psp: track generations of device key

[Daniel Zahka <daniel.zahka@gmail.com>]

On 8/14/25 10:07 AM, Paolo Abeni wrote:
> On 8/12/25 2:29 AM, Daniel Zahka wrote:
>> +void psp_assocs_key_rotated(struct psp_dev *psd)
>> +{
>> +	struct psp_assoc *pas, *next;
>> +
>> +	/* Mark the stale associations as invalid, they will no longer
>> +	 * be able to Rx any traffic.
>> +	 */
>> +	list_for_each_entry_safe(pas, next, &psd->prev_assocs, assocs_list)
>> +		pas->generation |= ~PSP_GEN_VALID_MASK;
>> +	list_splice_init(&psd->prev_assocs, &psd->stale_assocs);
>> +	list_splice_init(&psd->active_assocs, &psd->prev_assocs);
> AFAICS the prev_assocs size is unbounded, and keep increasing at each
> key rotation, am I correct?

psp_assoc objects are added to the active list during psp_assoc_create() 
in the rx-assoc netlink op, and then removed from whichever of the three 
lists it happens to be on during psp_assoc_free(), which is called when 
its refcount goes to 0. So basically, a key rotation will shift the 
psp_assoc's associated with the device around in terms of bookkeeping, 
but the total length of these three lists combined is determined only by 
the number of sockets in the system that have entered the rx-assoc 
state, and have yet to be closed. For now, there can only ever be one 
assoc per socket.

> In case of extreme long uptime (sometime
> happens :) or if the user-space goes wild, that could potentially
> consume unbound amount of memory. Could memory accounting or some hard
> limit make sense here?

I suppose a hard limit could make sense if adding one assoc per socket 
could be abused, but that is a different issue than if there is some way 
to use the uapi to create a psp_assoc leak.