Possible unaligned access in TCP mode

[LGA1150]

In UDP mode, a received OpenVPN data packet typically looks like:

IP header || UDP header || 4-byte opcode || 4-byte seq-no || 16-byte AEAD tag || ciphertext

The data area begins right after the UDP header, as long as the outer IP header is aligned, the 4-byte opcode and subsequent fields are also aligned.

In TCP mode, because TCP is a byte stream, an OpenVPN data packet may start at any offset within the TCP payload.

For example, a TCP segment may contain:

IP header || TCP header || 2-byte length || 4-byte opcode || 4-byte seq-no || 16-byte AEAD tag || ciphertext

or, if a packet spans multiple segments:

IP header || TCP header || (tail of previous ciphertext) || 2-byte length || 4-byte opcode || 4-byte seq-no || ...

ovpn uses strparser to process the TCP stream. strparser does not copy packet data - it only clones skbs and uses skb_shared_info::frag_list for continuation when one data packet spans multiple TCP segments.

As a result:

• The 4-byte opcode and 4-byte sequence number are not guaranteed to be aligned.
• After in-place decryption, the inner IP header may also become unaligned.

This is problematic on architectures without efficient unaligned access, such as MIPS. On MIPS, unaligned memory access triggers an exception and must be fixed in the exception handler (i.e., the cost is comparable to a syscall). Because the inner IP header is accessed multiple times during packet processing, this can severely impact performance.

The previous ovpn-dco module (and userspace implementation) did not suffer from this issue, because packet data were always copied into a newly allocated skb.

[ralflici]

Hi, thanks for reporting this. I can confirm that skb coalescing is problematic for protocols like openvpn over TCP. In fact, we're currently discussing a related issue on the netdev ML. The approach proposed in the RFC is intended to handle large skbs, but if it's considered correct we could extend it to all skbs on architectures without efficient unaligned access.

[LGA1150]

But the issue still exists without coalescing.

Given this example:

IP header || TCP header || 2-byte length || 4-byte opcode || 4-byte seq-no || 16-byte AEAD tag || ciphertext

opcode, seq-no, and ciphertext are unaligned because of the prepended 2-byte length.

[ralflici]

Sure, the part about skb coalescing is not very relevant for this issue. What I meant was that once we create a new skb with the content of the openvpn packet, we can control the layout to mitigate the misalignment caused by the 2-byte length. We could do this for every packet on strict architectures if that proves to be more efficient than handling the exceptions.

[LGA1150]

My proposal is to use get_unaligned_beXX helpers to fetch these 4-byte fields, and use out-of-place decryption to decrypt the ciphertext into a new skb.