netdev - Re: [PATCH net-next 12/13] genetlink: allow families to use split ops directly

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:   Thu, 20 Oct 2022 09:32:17 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
        pabeni@...hat.com, jiri@...nulli.us, razor@...ckwall.org,
        nicolas.dichtel@...nd.com, gnault@...hat.com,
        jacob.e.keller@...el.com, fw@...len.de
Subject: Re: [PATCH net-next 12/13] genetlink: allow families to use split
 ops directly

On Wed, 2022-10-19 at 12:57 -0700, Jakub Kicinski wrote:
> > Oh, I see now, you were basically saying "it's only 9% bigger for all
> > that extra flexibility" ... didn't read that right before.
> 
> Yup, BTW one annoying bit is that we treat maxattr == 0 as 
> "no validation" rather than "reject everything".
> 
> Right now I add a reject-all policy in the family itself (with two
> entries, argh), and hook it up to parameter-less dumps. But we could 
> do something else - like modify the behavior in case the op was declared
> as split at the family level.
> 
> I opted for having family add the reject-all policy because I code gen
> the policies based on YAML spec, anyway, so not much extra effort, and
> the uniformity between different type of ops seems worth maintaining.
> 
> WDYT?

Hmm. The codegen/YAML part likely won't really happen for all of the
families so perhaps some simplification would be good?

I feel like I probably should've changed this when adding
GENL_DONT_VALIDATE_DUMP_STRICT / GENL_DONT_VALIDATE_STRICT, but I guess
that's too late now :(

I guess we could add another set of flags, but that'd be annoying.

OTOH, it's nicer if future things are better, and we don't need to add a
"reject all" policy to all of them?

johannes