netdev - Re: [PATCH net] inet: bring NLM_DONE out to a separate recv() in inet_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: <ad393197-fd1a-4cd8-a371-f6529419193b@kernel.org>
Date: Sat, 1 Jun 2024 20:23:17 -0600
From: David Ahern <dsahern@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>,
 Stephen Hemminger <stephen@...workplumber.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
 pabeni@...hat.com, Jaroslav Pulchart <jaroslav.pulchart@...ddata.com>
Subject: Re: [PATCH net] inet: bring NLM_DONE out to a separate recv() in
 inet_dump_ifaddr()

On 6/1/24 5:48 PM, Jakub Kicinski wrote:
> On Sat, 1 Jun 2024 16:10:13 -0700 Stephen Hemminger wrote:
>> Sorry, I disagree.
>>
>> You can't just fix the problem areas. The split was an ABI change, and there could
>> be a problem in any dump. This the ABI version of the old argument 
>>   If a tree falls in a forest and no one is around to hear it, does it make a sound?
>>
>> All dumps must behave the same. You are stuck with the legacy behavior.

I don't agree with such a hard line stance. Mistakes made 20 years ago
cannot hold Linux back from moving forward. We have to continue
searching for ways to allow better or more performant behavior.

> 
> The dump partitioning is up to the family. Multiple families
> coalesce NLM_DONE from day 1. "All dumps must behave the same"
> is saying we should convert all families to be poorly behaved.
> 
> Admittedly changing the most heavily used parts of rtnetlink is very
> risky. And there's couple more corner cases which I'm afraid someone
> will hit. I'm adding this helper to clearly annotate "legacy"
> callbacks, so we don't regress again. At the same time nobody should
> use this in new code or "just to be safe" (read: because they don't
> understand netlink).

What about a socket option that says "I am a modern app and can handle
the new way" - similar to the strict mode option that was added? Then
the decision of requiring a separate message for NLM_DONE can be based
on the app. Could even throw a `pr_warn_once("modernize app %s/%d\n")`
to help old apps understand they need to move forward.