Messages in this thread | | | Subject | Re: [PATCH net-next v2 3/3] netlink: add validation of NLA_F_NESTED flag | From | Thomas Haller <> | Date | Tue, 23 Jul 2019 11:28:03 +0200 |
| |
On Tue, 2019-07-23 at 11:09 +0200, Michal Kubecek wrote: > On Tue, Jul 23, 2019 at 10:57:54AM +0200, Thomas Haller wrote: > > Does this flag and strict validation really provide any value? > > Commonly a netlink message is a plain TLV blob, and the meaning > > depends entirely on the policy. > > > > What I mean is that for example > > > > NLA_PUT_U32 (msg, ATTR_IFINDEX, (uint32_t) ifindex) > > NLA_PUT_STRING (msg, ATTR_IFNAME, "net") > > > > results in a 4 bytes payload that does not encode whether the data > > is > > a number or a string. > > > > Why is it valuable in this case to encode additional type > > information > > inside the message, when it's commonly not done and also not > > necessary? > > One big advantage of having nested attributes explicitly marked is > that > it allows parsers not aware of the semantics to recognize nested > attributes and parse their inner structure. > > This is very important e.g. for debugging purposes as without the > flag, > wireshark can only recurse into nested attributes if it understands > the > protocol and knows they are nested, otherwise it displays them only > as > an opaque blob (which is what happens for most netlink based > protocols). > Another example is mnl_nlmsg_fprintf() function from libmnl which is > also a valuable debugging aid but without NLA_F_NESTED flags it > cannot > show message structure properly.
Hi,
I don't question the use of the flag. I question whether it's necessary for kernel to strictly require the sending side to aid debuggability.
"e.g. for debugging purposes" makes it sound like it would be important for something else. I wonder what else.
Anyway. What you elaborate makes sense!! Thanks
My main point was to raise awareness that this is a problem for libnl3.
best, Thomas [unhandled content-type:application/pgp-signature] | |