netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Antonio Quartulli <antonio@openvpn.net>
Cc: netdev@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Ralf Lici <ralf@mandelbit.com>
Subject: Re: [PATCH net-next 6/8] ovpn: consolidate crypto allocations in one chunk
Date: Wed, 12 Nov 2025 17:29:16 +0100	[thread overview]
Message-ID: <aRS13OqKdhx4aVRo@krikkit> (raw)
In-Reply-To: <20251111214744.12479-7-antonio@openvpn.net>

2025-11-11, 22:47:39 +0100, Antonio Quartulli wrote:
> From: Ralf Lici <ralf@mandelbit.com>
> 
> Currently ovpn uses three separate dynamically allocated structures to
> set up cryptographic operations for both encryption and decryption. This
> adds overhead to performance-critical paths and contribute to memory
> fragmentation.
> 
> This commit consolidates those allocations into a single temporary blob,
> similar to what esp_alloc_temp() does.

nit: esp_alloc_tmp (no 'e')

> The resulting performance gain is +7.7% and +4.3% for UDP when using AES
> and ChaChaPoly respectively, and +4.3% for TCP.

Nice improvement! I didn't think it would be that much.


> Signed-off-by: Ralf Lici <ralf@mandelbit.com>
> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>

BTW, I didn't see any of these patches posted on the openvpn-devel
list or on netdev before this pull request. Otherwise I'd have
reviewed them earlier.


>  drivers/net/ovpn/crypto_aead.c | 151 +++++++++++++++++++++++++--------
>  drivers/net/ovpn/io.c          |   8 +-
>  drivers/net/ovpn/skb.h         |  13 ++-
>  3 files changed, 129 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/net/ovpn/crypto_aead.c b/drivers/net/ovpn/crypto_aead.c
> index cb6cdf8ec317..9ace27fc130a 100644
> --- a/drivers/net/ovpn/crypto_aead.c
> +++ b/drivers/net/ovpn/crypto_aead.c
> @@ -36,6 +36,105 @@ static int ovpn_aead_encap_overhead(const struct ovpn_crypto_key_slot *ks)
>  		crypto_aead_authsize(ks->encrypt);	/* Auth Tag */
>  }
>  
> +/*

nit: missing a 2nd * to make it kdoc?

> + * ovpn_aead_crypto_tmp_size - compute the size of a temporary object containing
> + *			       an AEAD request structure with extra space for SG
> + *			       and IV.
> + * @tfm: the AEAD cipher handle
> + * @nfrags: the number of fragments in the skb
> + *
> + * This function calculates the size of a contiguous memory block that includes
> + * the initialization vector (IV), the AEAD request, and an array of scatterlist
> + * entries. For alignment considerations, the IV is placed first, followed by
> + * the request, and then the scatterlist.
> + * Additional alignment is applied according to the requirements of the
> + * underlying structures.
> + *
> + * Return: the size of the temporary memory that needs to be allocated
> + */
> +static unsigned int ovpn_aead_crypto_tmp_size(struct crypto_aead *tfm,
> +					      const unsigned int nfrags)
> +{
> +	unsigned int len = crypto_aead_ivsize(tfm);
> +
> +	if (likely(len)) {

Is that right?

Previously iv was reserved with a constant size (OVPN_NONCE_SIZE), and
we're always going to write some data into ->iv via
ovpn_pktid_aead_write, but now we're only reserving the crypto
algorithm's IV size (which appear to be 12, ie OVPN_NONCE_SIZE, for
both chachapoly and gcm(aes), so maybe it doesn't matter).


> @@ -71,13 +171,15 @@ int ovpn_aead_encrypt(struct ovpn_peer *peer, struct ovpn_crypto_key_slot *ks,
>  	if (unlikely(nfrags + 2 > (MAX_SKB_FRAGS + 2)))
>  		return -ENOSPC;
>  
> -	/* sg may be required by async crypto */
> -	ovpn_skb_cb(skb)->sg = kmalloc(sizeof(*ovpn_skb_cb(skb)->sg) *
> -				       (nfrags + 2), GFP_ATOMIC);
> -	if (unlikely(!ovpn_skb_cb(skb)->sg))
> +	/* allocate temporary memory for iv, sg and req */
> +	tmp = kmalloc(ovpn_aead_crypto_tmp_size(ks->encrypt, nfrags),
> +		      GFP_ATOMIC);
> +	if (unlikely(!tmp))
>  		return -ENOMEM;
>  
> -	sg = ovpn_skb_cb(skb)->sg;
> +	iv = ovpn_aead_crypto_tmp_iv(ks->encrypt, tmp);
> +	req = ovpn_aead_crypto_tmp_req(ks->encrypt, iv);
> +	sg = ovpn_aead_crypto_req_sg(ks->encrypt, req);
>  
>  	/* sg table:
>  	 * 0: op, wire nonce (AD, len=OVPN_OP_SIZE_V2+OVPN_NONCE_WIRE_SIZE),
> @@ -105,13 +207,6 @@ int ovpn_aead_encrypt(struct ovpn_peer *peer, struct ovpn_crypto_key_slot *ks,
>  	if (unlikely(ret < 0))
>  		return ret;
>  
> -	/* iv may be required by async crypto */
> -	ovpn_skb_cb(skb)->iv = kmalloc(OVPN_NONCE_SIZE, GFP_ATOMIC);
> -	if (unlikely(!ovpn_skb_cb(skb)->iv))
> -		return -ENOMEM;
> -
> -	iv = ovpn_skb_cb(skb)->iv;
> -
>  	/* concat 4 bytes packet id and 8 bytes nonce tail into 12 bytes
>  	 * nonce
>  	 */
> @@ -130,11 +225,7 @@ int ovpn_aead_encrypt(struct ovpn_peer *peer, struct ovpn_crypto_key_slot *ks,
>  	/* AEAD Additional data */
>  	sg_set_buf(sg, skb->data, OVPN_AAD_SIZE);
>  
> -	req = aead_request_alloc(ks->encrypt, GFP_ATOMIC);
> -	if (unlikely(!req))
> -		return -ENOMEM;
> -
> -	ovpn_skb_cb(skb)->req = req;
> +	ovpn_skb_cb(skb)->crypto_tmp = tmp;

That should be done immediately after the allocation, so that any
failure before this (skb_to_sgvec_nomark, ovpn_pktid_xmit_next) will
not leak this blob? ovpn_aead_encrypt returns directly and lets
ovpn_encrypt_post handle the error and free the memory, but only after
 ->crypto_tmp has been set.

(same thing on the decrypt path)

-- 
Sabrina

  reply	other threads:[~2025-11-12 16:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11 21:47 [PATCH net-next 0/8] pull request: ovpn 2025-11-11 Antonio Quartulli
2025-11-11 21:47 ` [PATCH net-next 1/8] ovpn: use correct array size to parse nested attributes in ovpn_nl_key_swap_doit Antonio Quartulli
2025-11-14  2:26   ` Jakub Kicinski
2025-11-14 13:30     ` Antonio Quartulli
2025-11-11 21:47 ` [PATCH net-next 2/8] ovpn: pktid: use bitops.h API Antonio Quartulli
2025-11-15 10:10   ` Sabrina Dubroca
2025-11-11 21:47 ` [PATCH net-next 3/8] ovpn: notify userspace on client float event Antonio Quartulli
2025-11-14  2:21   ` Jakub Kicinski
2025-11-14  9:26     ` Ralf Lici
2025-11-14 14:22       ` Sabrina Dubroca
2025-11-14 14:43         ` Ralf Lici
2025-11-11 21:47 ` [PATCH net-next 4/8] ovpn: Allow IPv6 link-local addresses through RPF check Antonio Quartulli
2025-11-14 16:06   ` Sabrina Dubroca
2025-11-18 10:26     ` Antonio Quartulli
2025-11-11 21:47 ` [PATCH net-next 5/8] ovpn: add support for asymmetric peer IDs Antonio Quartulli
2025-11-13 13:58   ` Sabrina Dubroca
2025-11-13 14:12     ` Antonio Quartulli
2025-11-13 15:18       ` Sabrina Dubroca
2025-11-11 21:47 ` [PATCH net-next 6/8] ovpn: consolidate crypto allocations in one chunk Antonio Quartulli
2025-11-12 16:29   ` Sabrina Dubroca [this message]
2025-11-13  8:37     ` Antonio Quartulli
2025-11-13 10:35     ` Ralf Lici
2025-11-13 13:48       ` Sabrina Dubroca
2025-11-13 16:32         ` Ralf Lici
2025-11-14  2:25   ` Jakub Kicinski
2025-11-14  9:33     ` Ralf Lici
2025-11-11 21:47 ` [PATCH net-next 7/8] ovpn: use bound device in UDP when available Antonio Quartulli
2025-11-11 21:47 ` [PATCH net-next 8/8] ovpn: use bound address " Antonio Quartulli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aRS13OqKdhx4aVRo@krikkit \
    --to=sd@queasysnail.net \
    --cc=antonio@openvpn.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=ralf@mandelbit.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).