netdev - RE: [PATCH net-next v3 2/3] net/macsec: Add MACsec skb extension Rx Data path support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <PH0PR12MB544980DAD3694E4F532AB6B1BF899@PH0PR12MB5449.namprd12.prod.outlook.com>
Date:   Wed, 13 Jul 2022 06:21:25 +0000
From:   Lior Nahmanson <liorna@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Paolo Abeni <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Raed Salem <raeds@...dia.com>, Jiri Pirko <jiri@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>,
        Yossi Kuperman <yossiku@...dia.com>
Subject: RE: [PATCH net-next v3 2/3] net/macsec: Add MACsec skb extension Rx
 Data path support



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Wednesday, July 13, 2022 3:02 AM
> To: Lior Nahmanson <liorna@...dia.com>
> Cc: Paolo Abeni <pabeni@...hat.com>; edumazet@...gle.com;
> davem@...emloft.net; netdev@...r.kernel.org; Raed Salem
> <raeds@...dia.com>; Jiri Pirko <jiri@...dia.com>; Saeed Mahameed
> <saeedm@...dia.com>; Yossi Kuperman <yossiku@...dia.com>
> Subject: Re: [PATCH net-next v3 2/3] net/macsec: Add MACsec skb
> extension Rx Data path support
> 
> External email: Use caution opening links or attachments
> 
> 
> On Tue, 12 Jul 2022 06:50:52 +0000 Lior Nahmanson wrote:
> > i considered the usage of skb_metadata_dst, however i still think that
> > skb_ext will fit more to MACsec offload implementation for the following
> reasons:
> > 1. for Rx, each skb can have a different SCI and offloaded values which
> mandate allocation
> >     of metadata_dst for each skb which contradicts the desired usage for
> skb_metadata_dst where
> >     it's allocated once and a refcnt held whenever used.
> 
> How many distinct SCIs do you expect to see?

For Rx there is no limitation for the number of different SCIs.
from MACsec driver code:

struct macsec_secy {
...
     struct macsec_rx_sc __rcu *rx_sc; // each rx_sc contains unique SCI
};

static int macsec_add_rxsc(struct sk_buff *skb, struct genl_info *info)
{
...
    rx_sc = create_rx_sc(dev, sci);
...
}

where create_rx_sc() adds new rx_sc node to the secy->rx_sc list.

> 
> > 2. skb_ext method is used in a similar IPsec offload implementation which
> in the future could make it easier
> >     to refactor this section to unify all crypto offloads skb_ext usage.
> 
> MACSec is L2, IPsec has constraints we have to work around.