netdev - Re: [PATCH (repost) net-next] sched: add extack for tfilter

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:   Tue, 8 Nov 2022 10:55:44 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Hangbin Liu <liuhangbin@...il.com>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Cong Wang <xiyou.wangcong@...il.com>, netdev@...r.kernel.org,
        Jiri Pirko <jiri@...nulli.us>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        David Ahern <dsahern@...nel.org>
Subject: Re: [PATCH (repost) net-next] sched: add extack for tfilter_notify

On Tue, 8 Nov 2022 17:11:22 +0800 Hangbin Liu wrote:
> On Wed, Nov 02, 2022 at 04:36:46PM -0700, Jakub Kicinski wrote:
> > Eish.
> > 
> > Hangbin, I'm still against this. Please go back to my suggestions /
> > questions. A tracepoint or an attribute should do. Multi-part messages
> > are very hard to map to normal programming constructs, and I don't
> > think there is any precedent for mutli-part notifications.  
> 
> Hi Jakub,
> 
> I checked the doc[1], the NLMSGERR_ATTR_MSG could only be in NLMSG_ERROR and
> NLMSG_DONE messages. But the tfilter_notify() set the nlmsg type to
> RTM_NEWTFILTER. Would you like to help explain what you mean of using
> attribute? Should I send a NLMSG_ERROR/NLMSG_DONE message separately after the
> tfilter_notify()?
> 
> [1] https://www.kernel.org/doc/html//next/userspace-api/netlink/intro.html#ext-ack

My initial thought was to add an attribute type completely independent
of the attribute space defined in enum nlmsgerr_attrs, add it in the
TCA_* space. So for example add a TCA_NTF_WARN_MSG which will carry the
string message.

We can also create a nest to carry the full nlmsgerr_attrs attributes
with their existing types (TCA_NTF_EXT_ACK?). Each nest gets
to choose what attribute set it carries.

That said, most of the ext_ack attributes refer to an input attribute by
specifying the offset within the request. The notification recipient
will not be able to resolve those in any meaningful way. So since only
the string message will be of interest I reckon adding a full nest is
an unnecessary complication?