summaryrefslogtreecommitdiff
path: root/rust/kernel
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2025-09-16 17:09:37 -0700
committerPaolo Abeni <pabeni@redhat.com>2025-09-18 12:32:06 +0200
commite78851058b35deb9f2d60ecf698fbf7ae7790d09 (patch)
tree01593be924f430b59fffc810e3f8b8ef6fe018c6 /rust/kernel
parente97269257fe437910cddc7c642a636ca3cf9fb1d (diff)
psp: track generations of device key
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. The PSP Architecture specification mentions that an implementation should track device key generation when device keys are managed by the NIC. Some PSP implementations may opt to include this key generation state in decryption metadata each time a device key is used to decrypt a packet. If that is the case, that key generation counter can also be used when policy checking a decrypted skb against a psp_assoc. This is an optional feature that is not explicitly part of the PSP spec, but can provide additional security in the case where an attacker may have the ability to force key rotations faster than rekeying can occur. 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. Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250917000954.859376-11-daniel.zahka@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'rust/kernel')
0 files changed, 0 insertions, 0 deletions