netdev - Re: ynl - mutiple policies for one nested attr used in multiple cmds

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZONHpD7CPEWoQEq2@nanopsycho>
Date: Mon, 21 Aug 2023 13:16:52 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org
Subject: Re: ynl - mutiple policies for one nested attr used in multiple cmds

Fri, Aug 18, 2023 at 10:24:47PM CEST, kuba@...nel.org wrote:
>On Fri, 18 Aug 2023 20:11:16 +0200 Jiri Pirko wrote:
>> Okay, you don't have good solution, do you have at least the least bad
>> one? :)
>
>I was pondering this for the recent pp work:
>https://lore.kernel.org/all/20230816234303.3786178-13-kuba@kernel.org/
>search for NL_SET_ERR_MSG_ATTR.
>
>I ended up hand-rejecting the attrs which I didn't want.
>It's not great because the policy (netdev_page_pool_info_nl_policy)
>is shared so if someone adds stuff there they'll need to know
>to update all the rejects :[
>
>I guess a better way to code up the same idea would be to check if tb[]
>is NULL outside of expected attrs.

The problem is that with devlink, there no nostrict parsing. So the
like-to-be-ignored attrs if passed might error out during validation.

>
>Option #2 is to not use the auto-generated policy, and write the policy
>by hand in the kernel with the right members.

I'll go with this option for now I think.

>
>Option #3 is to add support for this to the YAML. With the existing
>concepts we would have to redefine all levels as subsets, and then
>we can override nested-attributes. A lot of typing. The YAML is really
>just a slightly decorated version of the policy tables. The policy
>tables in this case have to be separate.

Yeah. But eventually, I think this would be needed anyway to make yaml
to handle all the cases. Relying on the developer to do option #1 or #2
kinda defeats the inital yaml goal to avoid people mistakes, I think.