linux-kernel - Re: DSA vs envelope frames

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]

Message-ID: <344d53f8-1365-b478-ad81-44722932de91@lab.ntt.co.jp>
Date:   Thu, 1 Dec 2016 21:46:58 +0900
From:   Toshiaki Makita <makita.toshiaki@....ntt.co.jp>
To:     Nikita Yushchenko <nikita.yoush@...entembedded.com>,
        Andy Duan <fugang.duan@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Troy Kisky <troy.kisky@...ndarydevices.com>,
        Andrew Lunn <andrew@...n.ch>, Eric Nelson <eric@...int.com>,
        Philippe Reynes <tremyfr@...il.com>,
        Johannes Berg <johannes@...solutions.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     Chris Healy <cphealy@...il.com>,
        Fabio Estevam <fabio.estevam@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        lorian Fainelli <f.fainelli@...il.com>
Subject: Re: DSA vs envelope frames

On 2016/11/30 23:58, Nikita Yushchenko wrote:
>>> (1) When DSA is in use, frames processed by FEC chip contain DSA tag and
>>> thus can be larger than hardcoded limit of 1522. This issue is not
>>> FEC-specific, any driver that hardcodes maximum frame size to 1522 (many
>>> do) will have this issue if used with DSA.
>>
>> BTW I'm trying to introduce envelope frames to solve this kind of problems.
>> http://marc.info/?t=147496691500005&r=1&w=2
>> http://marc.info/?t=147496691500003&r=1&w=2
>> http://marc.info/?t=147496691500002&r=1&w=2
>> http://marc.info/?t=147496691500004&r=1&w=2
>> http://marc.info/?t=147496691500001&r=1&w=2
>>
>> It needs jumbo frame support of NICs though.
> 
> Thanks for pointing to this.
> 
> Indeed frame with DSA tag conceptually is an envelope frame.
> 
> ndev->env_hdr_len introduced by your patches, actually is explicitly
> handled difference between (MTU + 18) and frame that HW should allow.
> If this is known, hardware can be configured to work with DSA. At least
> FEC hardware that can send and receive "slightly larger" frames after
> simple register configuration.
> 
> Furthermore, since DSA configuration is known statically (it comes from
> device tree), ndo_set_env_hdr_len method could be automatically called
> at init, making setup working by default if driver supports that. And if
> not, perhaps can automatically lower MTU.
> 
> Looks like a solution :)
> 
> What's current status of this work?

Thank you for taking a look.
I'm planning to post v2 soon.

> What is not really clear - what if several tagging protocols are used
> together. AFAIU, things may be more complex that simple appending of
> tags, e.g. EDSA tag can carry VLAN id inside.

If kernel is aware of VLAN configuration, add 4 bytes + DSA tag size.
(I'm not familiar with how dsa knows vlan configuration, but probably
through switchdev_port_obj_add()? If so, dsa should be able to take into
account additional vlan tag size.)

If vlan tag is opaque from kernel, e.g. forwarding vlan tagged frames
without configuring vlan_filtering in bridge, admin needs to set
env_hdr_len manually. This is why I'm proposing manual operation.

Regards,
Toshiaki Makita