Message-ID: <a6f3efcf-f820-4b0e-8d2b-9b818b58fc2f@gmail.com>
Date: Thu, 26 Jun 2025 08:19:57 -0400
From: Daniel Zahka <daniel.zahka@...il.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
 Donald Hunter <donald.hunter@...il.com>, Jakub Kicinski <kuba@...nel.org>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 Jonathan Corbet <corbet@....net>, Andrew Lunn <andrew+netdev@...n.ch>
Cc: Saeed Mahameed <saeedm@...dia.com>, Leon Romanovsky <leon@...nel.org>,
 Tariq Toukan <tariqt@...dia.com>, Boris Pismenny <borisp@...dia.com>,
 Kuniyuki Iwashima <kuniyu@...gle.com>, Willem de Bruijn
 <willemb@...gle.com>, David Ahern <dsahern@...nel.org>,
 Neal Cardwell <ncardwell@...gle.com>, Patrisious Haddad
 <phaddad@...dia.com>, Raed Salem <raeds@...dia.com>,
 Jianbo Liu <jianbol@...dia.com>, Dragos Tatulea <dtatulea@...dia.com>,
 Rahul Rameshbabu <rrameshbabu@...dia.com>,
 Stanislav Fomichev <sdf@...ichev.me>,
 Toke Høiland-Jørgensen <toke@...hat.com>,
 Alexander Lobakin <aleksander.lobakin@...el.com>,
 Jacob Keller <jacob.e.keller@...el.com>, netdev@...r.kernel.org
Subject: 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:
>> From: Jakub Kicinski <kuba@...nel.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.

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

Powered by blists - more mailing lists