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

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Daniel Zahka wrote:
> 
> 
> On 6/25/25 8:20 PM, Willem de Bruijn wrote:
> > Daniel Zahka wrote:
> >> 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.

Ack. This is similar to the Google implementation on github.

> >
> > 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.

Right, the generation and SPI must both be checked before enqueuing
onto a socket.

Technically, the single MSB is sufficient, as it is never possible
for a new SPI for generation X to have match generation X - 1. And
even older generations will no longer be decrypted.
 
> >> 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.