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: <661566db-8fb2-85a2-3147-821c4cb26a1f@gmail.com>
Date:   Fri, 2 Oct 2020 11:01:04 -0700
From:   David Ahern <dsahern@...il.com>
To:     Johannes Berg <johannes@...solutions.net>, netdev@...r.kernel.org
Cc:     Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH] genl: ctrl: print op -> policy idx mapping

On 10/2/20 7:39 AM, Johannes Berg wrote:
> 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?

does not have to be in the kernel. Usability is important. Since you
have this compiled and easy to test, what is an example of the output
for this dump?