netdev - Re: [PATCH net-next v2 00/10] genetlink: support per-command policy dump

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: <47b6644999ce2946a262d5eac0c82e33057e7321.camel@sipsolutions.net>
Date:   Fri, 02 Oct 2020 22:59:00 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, andrew@...n.ch,
        jiri@...nulli.us, mkubecek@...e.cz, dsahern@...nel.org,
        pablo@...filter.org
Subject: Re: [PATCH net-next v2 00/10] genetlink: support per-command policy
 dump

On Fri, 2020-10-02 at 13:50 -0700, Jakub Kicinski wrote:
> 
> My thinking was that until kernel actually start using separate dump
> policies user space can assume policy 0 is relevant. But yeah, merging
> your changes first would probably be best.

Works for me. I have it based on yours. Just updated my branch (top
commit is 4d5045adfe90), but I'll probably only actually email it out
once things are a bit more settled wrt. your changes.

> I, OTOH, am having second thoughts about not implementing separate
> policies for dump right away, since Michal said he'll need them soon :)

:)

> Any ideas on how to do that cleanly? At some point it will make sense
> to have dumps and doits in separate structures, as you said earlier,
> but can we have "small" and "full" ops for both? That seems like too
> much :/

Not sure I understand what you just wrote :)

I had originally assumed dumps would be "infrequent", and so having the
small ops without dumps would be worthwhile. You said it wasn't true for
other users, so small ops still have .doit and .dumpit entries. Which is
fine?

But in the small ops anyway you don't have a policy pointer - I guess
you could have two "fallbacks" (for do and dump) in the family rather
than just one?

Another option - though it requires some rejiggering in my new policy
dump code - would be to key the lookup based on do/dump as well. Then
you could have the *same* op listed twice like

struct genl_ops my_ops[] = {
	{
		.cmd = SOMETHING,
		.doit = do_something,
		.policy = something_do_policy,
	},
	{
		.cmd = SOMETHING,
		.dumpit = dump_something,
		.policy = something_dump_policy,
	},
};

That way you only pay where needed? But ultimately with large ops you
already pay for the start/dump/done pointers, and you'd have that even
for the extra entry with _doit_ because ...

Unless we put three different kinds of ops (small, full-do, full-dump),
but that gets a bit awkward too?

johannes