netdev - Re: [PATCH net 1/2] ipv6: Dump route exceptions too in rt6_dump

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]

Message-ID: <20190610210121.5d543bb0@redhat.com>
Date:   Mon, 10 Jun 2019 21:01:21 +0200
From:   Stefano Brivio <sbrivio@...hat.com>
To:     "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
Cc:     "kafai@...com" <kafai@...com>,
        "dsahern@...il.com" <dsahern@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "weiwan@...gle.com" <weiwan@...gle.com>,
        "jishi@...hat.com" <jishi@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>
Subject: Re: [PATCH net 1/2] ipv6: Dump route exceptions too in
 rt6_dump_route()

Hi Matti,

On Mon, 10 Jun 2019 05:56:03 +0000
"Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com> wrote:

> Hi Dee Ho Peeps!
> 
> Wow Stefano, you seem to be quite a detective :) How on earth did you
> match my new email to this sole netdev intrusion done back at the 2011
> %) Impressive!

I was looking for lost UDP jokes. :)

> On Sat, 2019-06-08 at 17:02 +0200, Stefano Brivio wrote:
> 
> > 
> > - retry adding NLM_F_MATCH (for net-next and iproute-next) according
> >   to RFC 3549. Things changed a bit from 2011: we now have
> >   NLM_F_DUMP_FILTERED, iproute2 already uses it (ip neigh) and we
> >   wouldn't need to make iproute2 more complicated by handling old/new
> >   kernel cases. So I think this would be reasonable now.
> >   
> I am pretty sure the iproute would not have become more complicated
> back in 2011 even if we did push this change back then. iproute2 could
> have chosen to stick with own userspace filtering - supporting the
> NLM_F_MATCH flag back then would not have broken that. And if we did it
> back then - there now probably was some other tools utilizing the
> kernel filtering - and today the iproute2 could pretty safely drop the
> user-space route filtering code and transition to do filtering already
> in kernel. Well, that's a bit late to say today :)

Well, yes, it wouldn't have become more complicated. The difference
today is that, with NLM_F_DUMP_FILTERED codifying this, we could safely
and simply skip userspace filtering with just two lines, something like:

	if (n->nlmsg_flags & RTM_F_DUMP_FILTERED)
		return 1;

in filter_nlmsg().

> But yes, this unfinished thing has indeed haunted me during some black
> nights =) I would be delighted to see the proper NLM_F_MATCH support in
> kernel.
> 
> What stopped me back in the 2011 was actually Dave's comment that even
> if he could consider applying this change he would require it for IPv4
> too. And that makes perfect sense. It was just too much for me back
> then. I guess this has not changed - IPv6 and IPv4 should still handle
> these flags in a same way.

Indeed, we'll have to take care of both. It's on my to do list now, I
should get to it soon.

Right now my priority is to fix the fact that, at least with iproute2,
flushing IPv6 routed caches is simply not possible anymore. This looks
like a serious breakage to me.

-- 
Stefano