[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190405201115.13708-1-johannes@sipsolutions.net>
Date: Fri, 5 Apr 2019 22:11:08 +0200
From: Johannes Berg <johannes@...solutions.net>
To: netdev@...r.kernel.org
Subject: [RFC 1/7] netlink: expose policy to userspace
Now that it's working, here's the first draft of the code to
expose the netlink policy to userspace.
One thing I didn't think I would do but did anyway now is to
map the NLA_* type to a new attribute, and translate it for
userspace. This may not be the most convenient, but I think we
would prefer to have more flexibility with the NLA_* types in
the future.
For example, there's no real reason to have NLA_MSECS vs. NLA_U64,
and we may want to remove one. Similarly, we have a lot of types
for binary:
* NLA_UNSPEC - min length
* NLA_BINARY - max length
* NLA_MIN_LEN - min length
* NLA_EXACT_LEN - min & max length are equal
And obviously we may want to expand that in the future to have
*both* max and min length (we could easily do it using the range
we have now already, in fact.)
As we can expose both min and max length to userspace in optional
attributes, these can just be the same NL_ATTR_TYPE_BINARY.
I have a very hacky (and full of warnings) change to iproute2,
I've put it here but don't look closely:
https://p.sipsolutions.net/4c674acaf8d6ca71.txt
It will print out things like (for nl80211):
ID: 0x18 policy[0]:attr[4]: type=NUL_STRING max len:15
ID: 0x18 policy[0]:attr[5]: type=U32 range:[0,12]
ID: 0x18 policy[0]:attr[15]: type=BINARY max len:2304
ID: 0x18 policy[0]:attr[16]: type=U16 range:[1,2007]
ID: 0x18 policy[0]:attr[273]: type=NESTED policy:2 maxattr:5
ID: 0x18 policy[2]:attr[5]: type=NESTED_ARRAY policy:3 maxattr:4
ID: 0x18 policy[3]:attr[1]: type=BINARY min len:6 max len:6
ID: 0x18 policy[3]:attr[2]: type=NESTED
ID: 0x18 policy[3]:attr[3]: type=NESTED policy:4 maxattr:2
[...]
I've omitted lots of lines, I get close to 200 entries for the
current nl80211 policy.
As far as mechanics go, this is based on my previous patchset to
allow making validation strict. In principle, it's orthogonal, but
I suspect it would have some conflicts to apply.
The combined code is also available in mac80211-next (kernel.org)
in the `netlink-policy-export' branch.
johannes
Powered by blists - more mailing lists