netdev - Re: [PATCH net-next 0/4] inet: Separate DSCP from ECN bits using new dscp

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: <20211217225224.GA4135@pc-4.home>
Date:   Fri, 17 Dec 2021 23:52:24 +0100
From:   Guillaume Nault <gnault@...hat.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        David Ahern <dsahern@...nel.org>,
        Russell Strong <russell@...ong.id.au>
Subject: Re: [PATCH net-next 0/4] inet: Separate DSCP from ECN bits using new
 dscp_t type

On Fri, Dec 17, 2021 at 06:55:43PM +0100, Toke Høiland-Jørgensen wrote:
> >> > Note that there's no equivalent of patch 3 for IPv6 (ip route), since
> >> > the tos/dsfield option is silently ignored for IPv6 routes.
> >> 
> >> Shouldn't we just start rejecting them, like for v4?
> >
> > I had some thoughs about that, but didn't talk about them in the cover
> > letter since I felt there was already enough edge cases to discuss, and
> > this one wasn't directly related to this series (the problem is there
> > regardless of this RFC).
> >
> > So, on the one hand, we have this old policy of ignoring unknown
> > netlink attributes, so it looks consistent to also ignore unused
> > structure fields.
> >
> > On the other hand, ignoring rtm_tos leads to a different behaviour than
> > what was requested. So it certainly makes sense to at least warn the
> > user. But a hard fail may break existing programs that don't clear
> > rtm_tos by mistake.
> >
> > I'm not too sure which approach is better.
> 
> So I guess you could argue that those applications were broken in the
> first place, and so an explicit reject would only expose this? Do you
> know of any applications that actually *function* while doing what you
> describe?

I don't know of any existing application that actually does. But it's
easy to imagine a developer setting only parts of the rtmsg structure
and leaving the rest uninitialised. Exposing the problem might not help
the end user, who may have no way to modify the broken program.

Also, for people using ifupdown (/etc/network/interfaces on Debian and
derivatives), rejecting a command can cancel the configuration of an
entire device section. So a stray tos option on an ip -6 route command
would now leave the network interface entirely unconfigured.

I'm not saying these situations exist, just trying to anticipate all
possible side effects.

> One thought could be to add the rejection but be prepared to back it out
> if it does turn out (during the -rc phase) that it breaks something?

Given that it's something that'd be easy to revert, maybe we can try
this approach.

> -Toke
>