Re: [PATCH net-next v1 04/15] psp: add support for socket-less psp associations

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

On Wed Nov 11, 2026 at 1:23 PM EST, Todd Bert Freed wrote:
>> I'm not sure the kernel actually needs any bookkeeping at all for these
>> generic rx spi allocations. You could probably just pass the spi, dev
>> id, key, and probably rotation count (as a device key generation of
>> sorts) to the user without creating a kernel object. For socket
>> psp_assocs, the rx state is consulted on the datapath before queueing to
>> the socket. For tx state in all psp_assocs, there is the possibility
>> that an SADB handle needs to be cleaned up. Neither of those apply here
>> or in the rest of the series as I understand it.
>>
>> I figure the tc ingress rule can just take the spi and dev id by value
>> rather than needing a reference to an object that we create here.
>
> That is how it works in this series. The tc psp decap rule (ingress) does not
> make reference to an rx assoc ; instead, it should have flower matches on
> psp_spi, psp_ver, and psp_dev. That effectively ties it to packets from just
> one rx assoc.
>
> So why keep track of rx assoc objects at all? Two considerations.
>
> 1/ don't accept packets that correspond to a stale association. That is, even
> if the device decrypted the packet, it should be dropped if the device key
> which minted the assoc's SPI is two rotations behind. For psp socket offload
> that is enforced in __psp_sk_rx_policy_check() with the pas->generation
> check.
>

I asked why we needed to keep track of socketless rx assoc objects. The
above applies to the existing transport mode code, which is my point.
The rx state from the assoc is looked up from the datapath. It doesn't
seem like that is the case in this series.

> The spec permits SPIs to be reused immediately after two rotations. So the
> device could decrypt a packet with a SPI that is more than two rotations old
> in that case, or if a previous packet is being replayed, for example.
>

A SPI that is two generations old will cause and auth error on rx. The
hazard is that an old tc rule with a SPI from two generations ago can
alias a different SPI from this generation. Userspace can just flush old
rules before doing a key rotation. That is why I suggested including a
'rotations' attribute, although that is probably not even necessary to
keep track of which rules need to be flushed.

> 2/ hardware offload. the solution to #1 should be able to be fully offloaded
> to the device. psp tunnel mode will be hw offload only, and is implemented
> in the eswitch with connect-x.
>
> We could add a psp_gen flower match to replicate the pas->generation
> check, but the device has no access to the pas and can't offload that.
>
> Keeping track of the rx assoc means that the kernel can take action on the
> "this assoc is now stale" event. Possibly by enumerating the tc rules and
> either deleting them, or marking them stale for userspace to reap.
>

I think it makes more sense for userspace to just get rid of the rules
before rotating the keys. 

> -Todd