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
| ||
|
Message-ID: <2a49231c-496d-132a-93e1-8a2071a35b08@6wind.com> Date: Fri, 23 Sep 2022 17:42:33 +0200 From: Nicolas Dichtel <nicolas.dichtel@...nd.com> To: Jakub Kicinski <kuba@...nel.org> Cc: Guillaume Nault <gnault@...hat.com>, Hangbin Liu <liuhangbin@...il.com>, netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Ido Schimmel <idosch@...dia.com>, Petr Machata <petrm@...dia.com>, Florent Fourcot <florent.fourcot@...irst.fr>, Nikolay Aleksandrov <razor@...ckwall.org> Subject: Re: [PATCH net-next] rtnetlink: Honour NLM_F_ECHO flag in rtnl_{new, set}link Le 23/09/2022 à 15:48, Jakub Kicinski a écrit : > Let me clarify one more time in case Hangbin is waiting for > the discussion to resolve... > > On Fri, 23 Sep 2022 10:43:53 +0200 Nicolas Dichtel wrote: >> Le 22/09/2022 à 16:51, Guillaume Nault a écrit : >>> I just don't see any way to pass a handle back to user space at the >>> moment. The echo mechanism did that and was generic to all netlink >>> families (as long as nlmsg_notify() was called with the right >>> parameters). > > In NEWLINK, right? In NEWLINK there is no way to pass it back > at the moment. A newly added command can just respond with the handle > always. The problem with NEWLINK is that it _used to_ not respond so > we can't make it start responding because it will confuse existing user > space. > > At the protocol level NEW is no different than GET, whether it sends > a response back is decided by whoever implements the command. > > So yes, for NEWLINK we need a way to inform the kernel that user space > wants a reply. It can be via ECHO, it could be via a new attr. > > What I'm trying to argue about is *not* whether NEWLINK should support > ECHO but whether requiring ECHO to get a response for newly added > CREATE / NEW commands is a good idea. I think it is not, and new > commands should just always respond with the handle. Sure, but I don't see how we can enforce this. > > My main concern with using ECHO is that it breaks the one-to-one > relationship between a request and a response. There may be multiple > notifications generated due to a command, and if we want to retain > the "ECHO will loop back to you all resulting notifications" semantics, > which I think we should, then there can be multiple "responses". Thanks for the detailed explanation. > > This also has implications for the command IDs used in notifications. > A lot of modern genl families use different IDs for notifications to > make it easily distinguishable from responses. I didn't know that. Indeed, it's a good idea.
Powered by blists - more mailing lists