netdev - Re: [PATCH net-next v1 02/12] tools/net/ynl: Support sub-messages in nested attribute spaces

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: <029065d6-faaf-4e58-ac06-4e11c2ded02c@intel.com>
Date: Thu, 1 Feb 2024 12:53:08 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, Donald Hunter <donald.hunter@...il.com>
CC: <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, "Eric
 Dumazet" <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, "Jonathan
 Corbet" <corbet@....net>, <linux-doc@...r.kernel.org>, Breno Leitao
	<leitao@...ian.org>, Jiri Pirko <jiri@...nulli.us>, Alessandro Marcolini
	<alessandromarcolini99@...il.com>, <donald.hunter@...hat.com>
Subject: Re: [PATCH net-next v1 02/12] tools/net/ynl: Support sub-messages in
 nested attribute spaces

On 1/29/2024 5:42 PM, Jakub Kicinski wrote:
> Whether YNL specs should replace policy dumps completely (by building
> the YAML into the kernel, and exposing via sysfs like kheaders or btf)
>  - I'm not sure. I think I used policy dumps twice in my life. They
> are not all that useful, IMVHO...

Many older genetlink/netlink families don't have a super robust or
specific policy. For example, devlink has a single enum for all
attributes, and the policy is not specified per command. The policy
simply accepts all attributes for every command. This means that you
can't rely on policy to decide whether an attribute has meaning for a
given command.

Unfortunately, we can't really change this because it ultimately counts
as uAPI and we require that existing working functionality continues
working in the future. I personally find this too stringent as sending
such junk attributes requires someone going out of their way to write
the messages and add extra attributes. In most cases I think sane
users/software would rather be informed that they are sending data which
is not relevant.

However, I can understand the point that the userspace software
"worked", and we don't want to break existing applications just because
of a kernel upgrade.

The YNL spec does this by telling you at every layer of nesting which
set of attributes are allowed and with what values. Even if we can't
enforce this for older families its still useful information to report
in some manner.

In addition, the YNL spec is more readable than the policy dumps which
essentially require a separate tool to parse out everything and convert
to something useful.