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: <b65723e8-aeec-4c4d-83b9-6119d5297f8f@nvidia.com>
Date: Wed, 29 May 2024 22:01:52 +0200
From: Boris Pismenny <borisp@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
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 29.05.2024 20:50, Jakub Kicinski wrote:
> 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.

IIUC, you refer to tunnel mode as if it offloads
encryption alone while keeping headers intact. But,
what I had in mind is a fully offloaded tunnel.
This is called packet offload mode in IPsec,
and with encryption such offloads rely on TC.

Note that the main use-case for PSP tunnel mode,
unlike transport mode, is carrying VM traffic as
indicated by the spec:
"The tunnel mode packet format is typically used in
virtualized environments.". With virtualization, encap/decap offload is an implicit assumption if not a performance necessity.
>> - 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.

I can imagine how this will work, but there are a few issues:
- Guests may run out of Tx keys, but they can't initiate key
rotation without affecting others. This fate sharing between
VMs seems undesirable.
- Unclear what sort of mediation is the hypervisor expected
to provide: on the one hand, block a key rotation request and
the requesting guest is denied service, on the other hand,
allow key rotation and a guest may spam these requests to
the hypervisor, which will also spam other VMs with
notifications of key rotation.

>
>> 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.