netdev - Re: [PATCH] genl: ctrl: print op -> policy idx mapping

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: <58172ec0f7e74c63206121bf6d8f02481f47ee5a.camel@sipsolutions.net>
Date:   Fri, 02 Oct 2020 16:39:50 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     David Ahern <dsahern@...il.com>, netdev@...r.kernel.org
Cc:     Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH] genl: ctrl: print op -> policy idx mapping

On Fri, 2020-10-02 at 07:29 -0700, David Ahern wrote:
> On 10/2/20 3:26 AM, Johannes Berg wrote:
> > diff --git a/genl/ctrl.c b/genl/ctrl.c
> > index 68099fe97f1a..c62212b40fa3 100644
> > --- a/genl/ctrl.c
> > +++ b/genl/ctrl.c
> > @@ -162,6 +162,16 @@ static int print_ctrl(struct rtnl_ctrl_data *ctrl,
> >  		__u32 *ma = RTA_DATA(tb[CTRL_ATTR_MAXATTR]);
> >  		fprintf(fp, " max attribs: %d ",*ma);
> >  	}
> > +	if (tb[CTRL_ATTR_OP_POLICY]) {
> > +		const struct rtattr *pos;
> > +
> > +		rtattr_for_each_nested(pos, tb[CTRL_ATTR_OP_POLICY]) {
> > +			__u32 *v = RTA_DATA(pos);
> > +
> > +			fprintf(fp, " op %d has policy %d",
> > +				pos->rta_type, *v);
> 
> did you look at pretty printing the op and type? I suspect only numbers
> are going to cause a lot of staring at header files while counting to
> decipher number to text.

I didn't really, but it's also rather tricky?

The policy index can't be pretty printed anyway, it's literally an
ephemeral index that's valid only within that dump operation. Not that a
next one might be different, but if you change the kernel it may well
be.

Pretty-printing the op would mean maintaining all those strings in the
policy (or so) in the kernel? That seems like a _lot_ of memory usage
(as well as new code), just for this?

And otherwise it can't really be done generically in 'genl' because it
doesn't know anything about the families...

For a specific family you can, I guess. E.g. for nl80211 I might add
policy dump support with op and attribute type pretty-printing, based on
generating string tables from nl80211.h at build time.

But in general, I don't see how that could be doable.

Oh, and completely unrelated, but I forgot to mention it before: this
patch of course depends on the corresponding kernel patches I had posted
a bit earlier.

johannes