netdev - Re: [PATCH net-next v5 5/5] macsec: Don't rely solely on the dst MAC address to identify destination MACsec device

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 18 Apr 2023 14:35:48 +0000
From:   Subbaraya Sundeep Bhatta <sbhatta@...vell.com>
To:     Sabrina Dubroca <sd@...asysnail.net>
CC:     "ehakim@...dia.com" <ehakim@...dia.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "leon@...nel.org" <leon@...nel.org>,
        Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        Naveen Mamindlapalli <naveenm@...vell.com>,
        "atenart@...nel.org" <atenart@...nel.org>,
        Geethasowjanya Akula <gakula@...vell.com>
Subject: Re: [PATCH net-next v5 5/5] macsec: Don't rely solely on the dst MAC
 address to identify destination MACsec device

Hi,

>-----Original Message-----
>From: Sabrina Dubroca <sd@...asysnail.net>
>Sent: Tuesday, April 18, 2023 4:18 PM
>To: Subbaraya Sundeep Bhatta <sbhatta@...vell.com>
>Cc: ehakim@...dia.com; davem@...emloft.net; kuba@...nel.org;
>pabeni@...hat.com; edumazet@...gle.com; netdev@...r.kernel.org;
>leon@...nel.org; Sunil Kovvuri Goutham <sgoutham@...vell.com>; Naveen
>Mamindlapalli <naveenm@...vell.com>; atenart@...nel.org
>Subject: Re: [PATCH net-next v5 5/5] macsec: Don't rely solely on the dst
>MAC address to identify destination MACsec device
>
>2023-04-14, 06:32:28 +0000, Subbaraya Sundeep Bhatta wrote:
>> Hi,
>>
>> >-----Original Message-----
>> >From: Emeel Hakim <ehakim@...dia.com> <ehakim@...dia.com>
>> >Sent: Thursday, April 13, 2023 4:26 PM
>> >To: davem@...emloft.net; kuba@...nel.org; pabeni@...hat.com;
>> >edumazet@...gle.com; sd@...asysnail.net
>> >Cc: netdev@...r.kernel.org; leon@...nel.org; Emeel Hakim
>> ><ehakim@...dia.com>
>> >Subject: [PATCH net-next v5 5/5] macsec: Don't rely solely on the dst
>> >MAC address to identify destination MACsec device
>> >
>> >Offloading device drivers will mark offloaded MACsec SKBs with the
>> >corresponding SCI in the skb_metadata_dst so the macsec rx handler
>> >will know to which interface to divert those skbs, in case of a
>> >marked skb and a mismatch on the dst MAC address, divert the skb to
>> >the macsec net_device where the macsec rx_handler will be called to
>> >consider cases where relying solely on the dst MAC address is insufficient.
>> >
>> >One such instance is when using MACsec with a VLAN as an inner
>> >header, where the packet structure is ETHERNET | SECTAG | VLAN.
>> >In such a scenario, the dst MAC address in the ethernet header will
>> >correspond to the VLAN MAC address, resulting in a mismatch.
>> >
>>
>> I did below commands:
>> ifconfig eth2 up
>> ip link add link eth2 macsec0 type macsec sci cacbcd4142430002
>> ifconfig macsec0 hw ether ca:cb:cd:41:42:43 ip macsec offload macsec0
>> mac ifconfig macsec0 up ip macsec add macsec0 tx sa 0 on pn 5 key 02
>> 22222222222222222222222222222222 ip macsec add macsec0 rx sci
>> cacbcd2122230001 ip macsec add macsec0 rx sci cacbcd2122230001 sa 0 pn
>> 5 on key 01 11111111111111111111111111111111 ip link add link macsec0
>> vlan0 type vlan id 2
>>
>> ifconfig vlan0 hw ether ca:cb:cd:21:22:23 ifconfig vlan0 up [
>> 7106.072451] device macsec0 entered promiscuous mode [ 7106.077330]
>> device eth2 entered promiscuous mode
>>
>> macsec0 entered promisc mode when upper_dev mac address is not equal
>to its mac.
>> I think we should check if macsec device is in promisc mode instead of
>omitting mac address compare.
>> Also all drivers/hardware do not support md_dst->type ==
>> METADATA_MACSEC
>
>Is there a good reason to not make all drivers use metadata? It seems to me it
>would be cleaner than trying to guess where a packet belongs once it reaches
>the macsec core.
>
We need the support from hardware to use skb metadata.
On ingress side:
Hardware has to send metadata(SCI) as a side band signal to software to detect that packet has
been processed by macsec hardware block.
On egress side:
There has to be a provision for software to instruct hardware to use particular flow id/secy policy.

For our hardware I can support ingress side metadata by preserving sectag(SCI) in macsec hardware and
stripping sectag in driver (retrieve SCI) before giving to macsec core.
But for egress we only have TCAM. A TCAM flow is hit with match criteria of L2 header and action is to choose
corresponding secy policy (SCs, SA keys etc). 

I am checking with our hardware folks for solution wrt egress.

Thanks,
Sundeep

>--
>Sabrina