netdev - Re: Netlink NLM_F_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: <fef8b8d5-e07d-6d8f-841a-ead4ebee8d29@gmail.com>
Date:   Wed, 22 Jun 2022 22:01:37 -0600
From:   David Ahern <dsahern@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>, Ismael Luceno <iluceno@...e.de>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Netlink NLM_F_DUMP_INTR flag lost

On 6/22/22 5:55 PM, Jakub Kicinski wrote:
> On Wed, 22 Jun 2022 13:12:18 +0200 Ismael Luceno wrote:
>> So, just for clarification:
>>
>> Scenario 1:
>> - 64 KB packet is filled.
>> - protocol table shrinks
>> - Next iteration finds it's done
>> - next protocol clears the seq, so nothing is flaged
>> - ...
>> - NLMSG_DONE (not flagged)
>>
>> Scenario 2:
>> - 64 KB packet is filled.
>> - protocol table shrinks
>> - Next iteration finds it's done
>> - NLMSG_DONE (flagged with NLM_F_DUMP_INTR)
>>
>> So, in order to break as little as possible, I was thinking about
>> introducing a new packet iff it happens we have to signal INTR between
>> protocols.
>>
>> Does that sound good?
> 
> Right, the question is what message can we introduce here which would
> not break old user space?

I would hope a "normal" message with just the flags set is processed by
userspace. iproute2 does - lib/libnetlink.c, rtnl_dump_filter_l(). It
checks the nlmsg_flags first.

> 
> The alternative of not wiping the _DUMP_INTR flag as we move thru
> protocols seems more and more appealing, even tho I was initially
> dismissive.
> 
> We should make sure we do one last consistency check before we return 0
> from the handlers. Or even at the end of the loop in rtnl_dump_all().

Seems like netlink_dump_done should handle that for the last dump?

That said, in rtnl_dump_all how about a flags check after dumpit() and
send the message if INTR is set? would need to adjust the return code of
rtnl_dump_all so netlink_dump knows the dump is not done yet.