netdev - Re: [RFC net-next 00/15] add basic PSP encryption for TCP connections

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240529115032.48d103eb@kernel.org>
Date: Wed, 29 May 2024 11:50:32 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Boris Pismenny <borisp@...dia.com>
Cc: netdev@...r.kernel.org, pabeni@...hat.com,
 willemdebruijn.kernel@...il.com, gal@...dia.com, cratiu@...dia.com,
 rrameshbabu@...dia.com, steffen.klassert@...unet.com, tariqt@...dia.com,
 jgg@...dia.com
Subject: Re: [RFC net-next 00/15] add basic PSP encryption for TCP
 connections

On Wed, 29 May 2024 11:16:12 +0200 Boris Pismenny wrote:
> Thank you for doing this. I agree that TLS-like socket support
> is a main use-case. I'd like to hear what you think on a few
> other use-cases that I think should be considered as well
> since it may be difficult to add them as an afterthought:
> - Tunnel mode. What are your plans for tunnel mode? Clearly it
> is different from the current approach in some aspects, for
> example, no sockets will be involved.

The drivers should only decap for known L4 protos, I think that's
the only catch when we add tunnel support. Otherwise it should be
fairly straightforward. Open a UDP socket in the kernel. Get a key
+ SPI using existing ops. Demux within the UDP socket using SPI.

> - RDMA. The ultra ethernet group has mentioned RDMA encryption
> using PSP. Do you think that RDMA verbs will support PSP in
> a similar manner to sockets? i.e., using netlink to pass
> parameters to the device and linking QPs to PSP SAs?
> - Virtualization. How does PSP work from a VM? is the key
> shared with the hypervisor or is it private per-VM?

Depends on the deployment and security model, really, but I'd
expect the device key is shared, hypervisor is responsible for
rotations, and mediates all key ops from the guests.

> and what about containers?

I tried to apply some of the lessons learned from TLS offload and made
the "PSP device" a separate object. This should make it easy to
"forward" the offload to software/container netdevs.