Not to be confused with AMD's Platform Security Processor (PSP), but Google's PSP Security Protocol (PSP) for encryption in-transit for TCP network connections is now ready for the mainline kernel. This initial PSP encryption support for network connections is set to arrive with the upcoming Linux 6.18 kernel.After going through thirteen rounds of review, this Google PSP Security Protocol support for encrypting data in transit with TCP connections is expected to be merged for the Linux 6.18 kernel. This kernel code has been successfully tested with PSP-capable CX7 NICs.Google's PSP shares some concepts with IPsec ESP and is an encryption encapsulation layer on top of IP for large-scale data center needs. Google already has been using the PSP Security Protocol within their data centers while back in 2022 they open-sourced the architecture specification.Over IPsec, Google engineered PSP for greater simplicity, better functionality, and improved scalability. More background information on PSP can be found from this documentation patch . There is also the official Google PSP architecture specification (PDF). "This is v13 of the PSP RFC posted by Jakub Kicinski one year ago. General developments since v1 include a fork of packetdrill with support for PSP added, as well as some test cases, and an implementation of PSP key exchange and connection upgrade integrated into the fbthrift RPC library. ... The protocol can work in multiple modes including tunneling. But I'm mostly interested in using it as TLS replacement because of its superior offload characteristics. So this patch does three things: - it adds "core" PSP code PSP is offload-centric, and requires some additional care and feeding, so first chunk of the code exposes device info. This part can be reused by PSP implementations in xfrm, tunneling etc. - TCP integration TLS style Reuse some of the existing concepts from TLS offload, such as attaching crypto state to a socket, marking skbs as "decrypted", egress validation. PSP does not prescribe key exchange protocols. To use PSP as a more efficient TLS offload we intend to perform a TLS handshake ("inline" in the same TCP connection) and negotiate switching to PSP based on capabilities of both endpoints. This is also why I'm not including a software implementation. Nobody would use it in production, software TLS is faster, it has larger crypto records. - mlx5 implementation" Daniel Zahka wrote on the merge request now queued into net-next:With the initial patches, only the NVIDIA-Mellanox MLX5 network driver is adapted to make use of PSP.With this merge hitting the net-next networking subsystem tree this week, this initial PSP encryption support is expected to be submitted as part of the upcoming Linux 6.18 merge window.