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]

Date: Sun, 2 Jun 2024 20:42:14 -0600
From: David Ahern <dsahern@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Stephen Hemminger <stephen@...workplumber.org>, 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/2/24 3:59 PM, Jakub Kicinski wrote:
> On Sat, 1 Jun 2024 20:23:17 -0600 David Ahern wrote:
>>> 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.
> 
> That seems like a good solution, with the helper marking the "legacy"
> handlers - I hope it should be trivial to add such option and change
> the helper's behavior based on the socket state.
> 
>> Could even throw a `pr_warn_once("modernize app %s/%d\n")`
>> to help old apps understand they need to move forward.
> 
> Hm, do you think people would actually modernize all the legacy apps?

I have worked for a few companies that do monitor dmesg and when given
the right push will update apps. Best an OS can do.

> 
> Coincidentally, looking at Jaroslav's traces it appears that the app
> sets ifindex for the link dump, so it must not be opting into strict
> checking, either.

:-(

I should have added a warning back when the option was introduced - that
and a warning when options to a dump are ignored.