On 11.05.2024 01:11, Jakub Kicinski wrote:

On Fri, 10 May 2024 15:19:23 -0700 Saeed Mahameed wrote:

quoted

quoted

+PSP is designed primarily for hardware offloads. There is currently
+no software fallback for systems which do not have PSP capable NICs.
+There is also no standard (or otherwise defined) way of establishing
+a PSP-secured connection or exchanging the symmetric keys.
+
+The expectation is that higher layer protocols will take care of
+protocol and key negotiation. For example one may use TLS key exchange,
+announce the PSP capability, and switch to PSP if both endpoints
+are PSP-capable.

The documentation doesn't include anything about userspace, other than
highlevel remarks on how this is expected to work.

The cover letter does.

quoted

What are we planning for userspace? I know we have kperf basic support and
some experimental python library, but nothing official or psp centric.

Remind me, how long did it take for kernel TLS support to be merged
into OpenSSL? ;)

I believe it was bad timing for OpenSSL. The patches with kTLS support were
sitting in the main branch for long time, the problem was postponed release with
with jump to new versioning schema.

But I agree, there is no easy way to start coding user-space lib without initial
support from kernel.

quoted

I propose to start community driven project with a well established
library, with some concrete sample implementation for key negotiation,
as a plugin maybe, so anyone can implement their own key-exchange
mechanisms on top of the official psp library.

Yes, I should have CCed Meta's folks who work on TLS [1]. Adding them
now. More than happy to facilitate the discussion, maybe Willem can
CC the right Google folks, IDK who else...

We should start moving with the kernel support, IMO, until we do
the user space implementation is stalled. I don't expect that the
way we install keys in the kernel would be impacted by the handshake.

[1] https://github.com/facebookincubator/fizz