netdev - Re: [net-next] net: dsa: felix: disable always guard band bit for TAS config

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 07 Jun 2021 13:26:22 +0200
From:   Michael Walle <michael@...le.cc>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Vladimir Oltean <olteanv@...il.com>,
        UNGLinuxDriver@...rochip.com, alexandre.belloni@...tlin.com,
        allan.nielsen@...rochip.com,
        Claudiu Manoil <claudiu.manoil@....com>, davem@...emloft.net,
        idosch@...lanox.com, joergen.andreasen@...rochip.com,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        Po Liu <po.liu@....com>, vinicius.gomes@...el.com
Subject: Re: [net-next] net: dsa: felix: disable always guard band bit for TAS
 config

Hi Vladimir, Hi Xiaoliang,

Am 2021-05-07 14:19, schrieb Vladimir Oltean:
> Devices like Felix need the per-queue max SDU from the
> user - if that isn's specified in the netlink message they'll have to
> default to the interface's MTU.

Btw. just to let you and Xiaoliang know:

It appears that PORT_MAX_SDU isn't working as expected. It is used
as a fallback if QMAXSDU_CFG_n isn't set for the guard band
calculation. But it appears to be _not_ used for discarding any
frames. E.g. if you set PORT_MAX_SDU to 500 the port will still
happily send frames larger than 500 bytes. (Unless of course
you hit the guard band of 500 bytes). OTOH QMAXSDU_CFG_n works
as expected, it will discard oversized frames - and presumly will
set the guard band accordingly, I haven't tested this explicitly.

Thus, I wonder what sense PORT_MAX_SDU makes at all. If you set
the guard band to a smaller value than the MTU, you'll also need
to make sure, there will be no larger frames scheduled on that port.

In any case, the workaround is to set QMAXSDU_CFG_n (for all
n=0..7) to the desired max_sdu value instead of using PORT_MAX_SDU.

It might also make sense to check with the IP supplier.

In the case anyone wants to implement that for (upstream) linux ;)

-michael