netdev - Re: [PATCH net] selftests: forwarding: vxlan_bridge

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, 17 Feb 2020 10:59:04 +0800
From:   Hangbin Liu <liuhangbin@...il.com>
To:     Petr Machata <petrm@...lanox.com>
Cc:     Petr Machata <pmachata@...il.com>, netdev@...r.kernel.org,
        Ido Schimmel <idosch@...lanox.com>,
        "David S . Miller" <davem@...emloft.net>,
        Peter Dawson <petedaws@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH net] selftests: forwarding: vxlan_bridge_1d: fix tos value

On Fri, Feb 14, 2020 at 11:54:09AM +0100, Petr Machata wrote:
> >> > After commit 71130f29979c ("vxlan: fix tos value before xmit") we start
> >> > strict vxlan xmit tos value by RT_TOS(), which limits the tos value less
> >> 
> >> I don't understand how it is OK to slice the TOS field like this. It
> >> could contain a DSCP value, which will be mangled.
> >
> > Thanks for this remind. I re-checked the tos definition and found a summary
> > from Peter Dawson[1].
> >
> > IPv4/6 Header:0 |0 1 2 3 |0 1 2 3 |0 1 2 3 |0 1 2 3 |
> > RFC2460(IPv6)   |Version | Traffic Class   |        |
> > RFC2474(IPv6)   |Version | DSCP        |ECN|        |
> > RFC2474(IPv4)   |Version |  IHL   |    DSCP     |ECN|
> > RFC1349(IPv4)   |Version |  IHL   | PREC |  TOS   |X|
> > RFC791 (IPv4)   |Version |  IHL   |      TOS        |
> >
> > According to this I think our current IPTOS_TOS_MASK should be updated to 0xFC
> > based on RFC2474. But I'm not sure if there will have compatibility issue.
> > What do you think?
> 
> Looking at the various uses of RT_TOS, it looks like they tend to be
> used in tunneling and routing code. I think that in both cases it makes
> sense to convert to 0xfc. But I'm not ready to vouch for this :)

Yes, I also could not... Maybe David or Daniel could help give some comments?

> 
> What is the problem that commit 71130f29979c aims to solve? It's not
> clear to me from the commit message. What issues arise if the TOS is
> copied as is?

As the commit said, we should not use config tos directly. We should remove
the precedence field based on RFC1349 or ENC field based on RFC2474.

Thanks
Hangbin