Support out-of-place crypto operations

[LGA1150]

What about out-of-place crypto operations? It's possible to encrypt/decrypt a non-linear packet into a linear skb directly, avoiding an extra copy.

this should be what happens already. We use sg APIs to map the output in the same skb as input.
You don't think this is happening?

However, please let's open another issue to discuss separete topics.

Originally posted by @ordex in #28

ovpn-net-next/drivers/net/ovpn/crypto_aead.c

Line 319 in cbf42ac

aead_request_set_crypt(req, sg, sg, payload_len + tag_size, iv);

Out-of-place means src != dst. If a non-linear skb is received, it can be passed as src without linearization, while dst can be a newly allocated linear skb.

[ordex]

Maybe I am not understanding your suggestion: you want to switch from in-place crypto to out-of-place?
Why would that be better?

[LGA1150]

you want to switch from in-place crypto to out-of-place?

Yes.

Why would that be better?

We can avoid the memory copy (skb_copy_bits) to the linear skb.

[ordex]

We can avoid the memory copy (skb_copy_bits) to the linear skb.

Can you please point out in the code where the skb_copy_bits we would save is located?
This way I can better understand your suggestion. Thanks!

[ralflici]

@ordex it's the new patch for TCP (d4f687f), the one that allocates the new skb and copies the packet in it.

[ordex]

oh, so this would be a TCP only optimization

[ordex]

we can definitely look into it - it may be a little invasive because the crypto code has no idea whether the packet is coming from TCP or UDP.
But maybe a flag that could turn on or off this behaviour could be used.

However @LGA1150 , I'd suggest to first give the current code a go, because throughput improvement was already pretty high :D

[LGA1150]

I'd suggest to first give the current code a go, because throughput improvement was already pretty high :D

That's fine. Waiting for the next version ;)

[ordex]

The latest commit in the sources branch of ovpn-backports already contains all the fixes, if you want to give it a try.

[LGA1150]

The latest commit in the sources branch of ovpn-backports already contains all the fixes, if you want to give it a try.

On Kernel 6.18, do you recommend ovpn-backports or the in-tree ovpn?

[ralflici]

In theory the following fixes should already be in the 6.18 stable tree:

• d4f687f ovpn: tcp - fix packet extraction from stream
• 9456026 ovpn: tcp - don't deref NULL sk_socket member after tcp_close()
• b660b13 ovpn: fix VPN TX bytes counting
• a5ec7ba ovpn: fix possible use-after-free in ovpn_net_xmit
• 93686c4 ovpn: set sk_user_data before overriding callbacks

But there is no way to know when, or even whether, a distro shipping a 6.18-based kernel will pick up these fixes. Because of that, I recommend using ovpn-backports so you can test against the latest module snapshot.

[LGA1150]

The recent Linux security vulnerabilities, Copy Fail (CVE-2026-31431) and Dirty Frag (CVE Pending), are both related to in-place crypto operations that corrupt shared pages. Is it possible that ovpn is affected, too? @V4bel

[ralflici]

My understanding is that the relevant precondition for Copy Fail and Dirty Frag is that externally backed pages survive into a writable crypto destination scatterlist. ovpn does perform in-place AEAD, but both encrypt and decrypt call skb_cow_data() before building the scatterlist with skb_to_sgvec_nomark(). skb_cow_data() pulls paged skb frags into private skb storage before returning, so page-cache/shared frags should not reach the in-place crypto operation.

[LGA1150]

skb_cow_data() pulls paged skb frags into private skb storage before returning, so page-cache/shared frags should not reach the in-place crypto operation.

Makes sense. Switching to out-of-place can avoid the overhead of skb_cow_data(), though.