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]

Date:   Mon, 10 Jun 2019 05:56:03 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "kafai@...com" <kafai@...com>,
        "sbrivio@...hat.com" <sbrivio@...hat.com>
CC:     "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 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!

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 :)

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.

Br,
	Matti Vaittinen