From: Leon Romanovsky <leon@kernel.org>
To: Bharat Bhushan <bbhushan2@marvell.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
sgoutham@marvell.com, gakula@marvell.com, sbhatta@marvell.com,
hkelam@marvell.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, jerinj@marvell.com,
lcherian@marvell.com, richardcochran@gmail.com
Subject: Re: [net-next,v3 5/8] cn10k-ipsec: Add SA add/delete support for outb inline ipsec
Date: Thu, 30 May 2024 17:49:59 +0300 [thread overview]
Message-ID: <20240530144959.GC3884@unreal> (raw)
In-Reply-To: <20240528135349.932669-6-bbhushan2@marvell.com>
On Tue, May 28, 2024 at 07:23:46PM +0530, Bharat Bhushan wrote:
> This patch adds support to add and delete Security Association
> (SA) xfrm ops. Hardware maintains SA context in memory allocated
> by software. Each SA context is 128 byte aligned and size of
> each context is multiple of 128-byte. Add support for transport
> and tunnel ipsec mode, ESP protocol, aead aes-gcm-icv16, key size
> 128/192/256-bits with 32bit salt.
>
> Signed-off-by: Bharat Bhushan <bbhushan2@marvell.com>
> ---
> v2->v3:
> - Removed memset to zero wherever possible
> (comment from Kalesh Anakkur Purayil)
> - Corrected error hanlding when setting SA for inbound
> (comment from Kalesh Anakkur Purayil)
> - Move "netdev->xfrmdev_ops = &cn10k_ipsec_xfrmdev_ops;" to this patch
> This fix build error with W=1
>
> .../marvell/octeontx2/nic/cn10k_ipsec.c | 452 ++++++++++++++++++
> .../marvell/octeontx2/nic/cn10k_ipsec.h | 114 +++++
> 2 files changed, 566 insertions(+)
<...>
> +static int cn10k_ipsec_validate_state(struct xfrm_state *x)
> +{
> + struct net_device *netdev = x->xso.dev;
> +
> + if (x->props.aalgo != SADB_AALG_NONE) {
> + netdev_err(netdev, "Cannot offload authenticated xfrm states\n");
> + return -EINVAL;
> + }
> + if (x->props.ealgo != SADB_X_EALG_AES_GCM_ICV16) {
> + netdev_err(netdev, "Only AES-GCM-ICV16 xfrm state may be offloaded\n");
> + return -EINVAL;
> + }
> + if (x->props.calgo != SADB_X_CALG_NONE) {
> + netdev_err(netdev, "Cannot offload compressed xfrm states\n");
> + return -EINVAL;
> + }
> + if (x->props.flags & XFRM_STATE_ESN) {
> + netdev_err(netdev, "Cannot offload ESN xfrm states\n");
> + return -EINVAL;
> + }
I afraid that this check will cause for this offload to be unusable in
real life scenarios. It is hard to imagine that someone will use offload
which requires rekeying every 2^32 packets.
> + if (x->props.family != AF_INET && x->props.family != AF_INET6) {
> + netdev_err(netdev, "Only IPv4/v6 xfrm states may be offloaded\n");
> + return -EINVAL;
> + }
> + if (x->props.mode != XFRM_MODE_TRANSPORT &&
> + x->props.mode != XFRM_MODE_TUNNEL) {
> + dev_info(&netdev->dev, "Only tunnel/transport xfrm states may be offloaded\n");
> + return -EINVAL;
> + }
> + if (x->id.proto != IPPROTO_ESP) {
> + netdev_err(netdev, "Only ESP xfrm state may be offloaded\n");
> + return -EINVAL;
> + }
> + if (x->encap) {
> + netdev_err(netdev, "Encapsulated xfrm state may not be offloaded\n");
> + return -EINVAL;
> + }
> + if (!x->aead) {
> + netdev_err(netdev, "Cannot offload xfrm states without aead\n");
> + return -EINVAL;
> + }
> +
> + if (x->aead->alg_icv_len != 128) {
> + netdev_err(netdev, "Cannot offload xfrm states with AEAD ICV length other than 128bit\n");
> + return -EINVAL;
> + }
> + if (x->aead->alg_key_len != 128 + 32 &&
> + x->aead->alg_key_len != 192 + 32 &&
> + x->aead->alg_key_len != 256 + 32) {
> + netdev_err(netdev, "Cannot offload xfrm states with AEAD key length other than 128/192/256bit\n");
> + return -EINVAL;
> + }
> + if (x->tfcpad) {
> + netdev_err(netdev, "Cannot offload xfrm states with tfc padding\n");
> + return -EINVAL;
> + }
> + if (!x->geniv) {
> + netdev_err(netdev, "Cannot offload xfrm states without geniv\n");
> + return -EINVAL;
> + }
> + if (strcmp(x->geniv, "seqiv")) {
> + netdev_err(netdev, "Cannot offload xfrm states with geniv other than seqiv\n");
> + return -EINVAL;
> + }
> + return 0;
> +}
I don't see check for supported offload type among these checks.
if (x->xso.type != XFRM_DEV_OFFLOAD_CRYPTO) {
....
next prev parent reply other threads:[~2024-05-30 14:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 13:53 [net-next,v3 0/8] cn10k-ipsec: Add outbound inline ipsec support Bharat Bhushan
2024-05-28 13:53 ` [net-next,v3 1/8] octeontx2-pf: map skb data as device writeable Bharat Bhushan
2024-05-28 13:53 ` [net-next,v3 2/8] octeontx2-pf: Move skb fragment map/unmap to common code Bharat Bhushan
2024-05-28 13:53 ` [net-next,v3 3/8] octeontx2-af: Disable backpressure between CPT and NIX Bharat Bhushan
2024-05-28 13:53 ` [net-next,v3 4/8] cn10k-ipsec: Initialize crypto hardware for outb inline ipsec Bharat Bhushan
2024-05-29 5:46 ` Kalesh Anakkur Purayil
2024-06-03 8:45 ` [EXTERNAL] " Bharat Bhushan
2024-05-28 13:53 ` [net-next,v3 5/8] cn10k-ipsec: Add SA add/delete support " Bharat Bhushan
2024-05-30 14:49 ` Leon Romanovsky [this message]
2024-06-03 9:04 ` [EXTERNAL] " Bharat Bhushan
2024-05-28 13:53 ` [net-next,v3 6/8] cn10k-ipsec: Process inline ipsec transmit offload Bharat Bhushan
2024-06-01 10:19 ` Simon Horman
2024-06-03 9:06 ` [EXTERNAL] " Bharat Bhushan
2024-06-02 6:51 ` Leon Romanovsky
2024-06-03 4:33 ` [EXTERNAL] " Sunil Kovvuri Goutham
2024-06-03 9:18 ` Bharat Bhushan
2024-05-28 13:53 ` [net-next,v3 7/8] cn10k-ipsec: Allow inline ipsec offload for skb with SA Bharat Bhushan
2024-05-28 13:53 ` [net-next,v3 8/8] cn10k-ipsec: Enable outbound inline ipsec offload Bharat Bhushan
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=20240530144959.GC3884@unreal \
--to=leon@kernel.org \
--cc=bbhushan2@marvell.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gakula@marvell.com \
--cc=hkelam@marvell.com \
--cc=jerinj@marvell.com \
--cc=kuba@kernel.org \
--cc=lcherian@marvell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=sbhatta@marvell.com \
--cc=sgoutham@marvell.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.