Re: [PATCH v2 10/17] psp: track generations of device key

On 6/25/25 8:20 PM, Willem de Bruijn wrote:

Daniel Zahka wrote:

quoted

From: Jakub Kicinski <kuba@kernel.org>

There is a (somewhat theoretical in absence of multi-host support)
possibility that another entity will rotate the key and we won't
know. This may lead to accepting packets with matching SPI but
which used different crypto keys than we expected. Maintain and
compare "key generation" per PSP spec.

One option is for the device to include a generation id along
with the session key and SPI.

It already does, as the MSB of the SPI determines which of the two
device keys is responsible.

But this could be extended to multi-bit.

The idea behind psd->generation is that the device can give each device 
key an id, and then on rx, the device will fill out the rx metadata with 
the id for whatever key was used for decryption. The policy checking 
code in the tcp layer checks the generation from the rx metadata against 
the one in the psp_assoc from when the session key was created. In this 
way, psd->generation is opaque. It would be most intuitive for it to be 
something like additional MSBs of the spi space, though.

Another option to avoid this issue is for a device to notify the host
whenever it rotates the key. This can be due to a multi-host scenario
where another host requested a rotation. Or it may be a device
initiated rotation as it runs out of 31b SPI.
  

This will need to be supported in any case. I think this is all to deal 
with any potential races against getting a spi after a rotation and 
immediately trying to use it to forge a packet targeted towards a socket 
on the same machine that may now have that same spi from a previous 
device key. I'm not sure if that is a legitimate concern, but if the 
device has the ability to provide extra device key generation bits with 
rx decryption metadata, this just uses that.

quoted

Since we're tracking "key generations" more explicitly now,
maintain different lists for associations from different generations.
This way we can catch stale associations (the user space should
listen to rotation notifications and change the keys).

Drivers can "opt out" of generation tracking by setting
the generation value to 0.

Why?

If the device doesn't support this capability of filling out rx metadata 
with additional key generation bits beyond the MSB of the spi.