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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <685d52e4bd4c4_2dcd9a2947c@willemb.c.googlers.com.notmuch>
Date: Thu, 26 Jun 2025 10:02:12 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Daniel Zahka <daniel.zahka@...il.com>, 
 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

Daniel Zahka wrote:
> 
> 
> 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.

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.