netdev - Re: Genetlink per cmd policies

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: <fce613c2b4c797de4be413afddf872fd6dae9ef8.camel@sipsolutions.net>
Date:   Wed, 30 Sep 2020 18:06:28 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>,
        Michal Kubecek <mkubecek@...e.cz>, dsahern@...nel.org,
        pablo@...filter.org
Cc:     netdev@...r.kernel.org
Subject: Re: Genetlink per cmd policies

Hi Jakub,

> I'd like to be able to dump ethtool nl policies, but right now policy
> dumping is only supported for "global" family policies.

Did ethtool add per-command policies?

> Is there any reason not to put the policy in struct genl_ops, 
> or just nobody got to it, yet?
> 
> I get the feeling that this must have been discussed before...

Sort of, yeah.

We actually *had* per-command policies, and I removed it in commit
3b0f31f2b8c9 ("genetlink: make policy common to family"), mostly because
the maxattr is actually in the family not the op, so having a policy in
each op was never really a good idea and well-supported.

Additionally, having the pointer in each op (and if you want to do it
right you also need maxattr in each op) significantly increases the
binary size there, as well as boilerplate code to type it out, though
the latter could be avoided by "falling back" to the family policy.

So at the time, that reduced nl80211 size by 824 bytes, which I guess
means we had 103 ops at the time. Doing it right with maxattr would cost
twice as much as just the policy pointer, and we probably have a few
more ops now, so we're looking at a cost of ~1.6k for it.

Personally, I'm not really convinced that there really is a need for it,
but then I haven't really looked that much at ethtool. In most cases,
you want some "common" attributes for the family, even if it's only the
interface index or such, because also on the userspace side that's
awkward if you have to really build *everything* including such
identifying information per command. The one or two families that
actually had different policies per command (at the time I removed it)
actually solved this by "aliasing" the same attribute number between the
different policies, but again that feels rather awkward ...

That's the historic info I guess - I'll take a look at ethtool later and
see what it's doing there.

johannes