Re: [PATCH v2 01/17] psp: add documentation

On 6/25/25 7:42 PM, Willem de Bruijn wrote:

Daniel Zahka wrote:

quoted

From: Jakub Kicinski <kuba@kernel.org>

Add documentation of things which belong in the docs rather
than commit messages.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
+Driver notes
+------------
+
+Drivers are expected to start with no PSP enabled (``psp-versions-ena``
+in ``dev-get`` set to ``0``) whenever possible. The user space should
+not depend on this behavior, as future extension may necessitate creation
+of devices with PSP already enabled, nonetheless drivers should not enable
+PSP by default. Enabling PSP should be the responsibility of the system
+component which also takes care of key rotation.
+
+Note that ``psp-versions-ena`` is expected to be used only for enabling
+receive processing. The device is not expected to reject transmit requests

This means skb encryption for already established connections only,
right? Establishing tx offload will be rejected for new connections.

As it is now, psp-versions-ena is only used to affect the device 
configuration. So, the code for handling sockets i.e. 
psp_nl_rx_assoc_doit() / psp_nl_tx_assoc_doit() does not include a check 
against anything controlled by this setting. We only have a check 
against psp_dev->caps->versions, which is fixed after psp_dev_create(). 
Perhaps that would make sense though.

quoted

+after ``psp-versions-ena`` has been disabled. User may also disable
+``psp-versions-ena`` while there are active associations, which will
+break all PSP Rx processing.
+
+Drivers are expected to ensure that device key is usable upon init
+(working keys can be allocated), and that no duplicate keys may be generated
+(reuse of SPI without key rotation). Drivers may achieve this by rotating
+keys twice before registering the PSP device.

Since the device returns a { session_key, spi } pair, risk of reuse
is purely in firmware. I don't follow the need for the extra double
rotation.

Indeed that last sentence is superfluous. Re-initializing a device 
shouldn't leave a device key from a previous initialization, while 
resetting the spi space. If something like that were possible, it should 
probably be obvious to the driver writer to do something like double 
rotate the keys.