From: David Ahern <dsahern@kernel.org>
To: netdev@vger.kernel.org, davem@davemloft.net
Cc: christian@brauner.io, jbenc@redhat.com,
stephen@networkplumber.org, David Ahern <dsahern@gmail.com>
Subject: [PATCH RFC v2 net-next 00/25] rtnetlink: Add support for rigid checking of data in dump request
Date: Mon, 1 Oct 2018 17:28:26 -0700 [thread overview]
Message-ID: <20181002002851.5002-1-dsahern@kernel.org> (raw)
From: David Ahern <dsahern@gmail.com>
There are many use cases where a user wants to influence what is
returned in a dump for some rtnetlink command: one is wanting data
for a different namespace than the one the request is received and
another is limiting the amount of data returned in the dump to a
specific set of interest to userspace, reducing the cpu overhead of
both kernel and userspace. Unfortunately, the kernel has historically
not been strict with checking for the proper header or checking the
values passed in the header. This lenient implementation has allowed
iproute2 and other packages to pass any struct or data in the dump
request as long as the family is the first byte. For example, ifinfomsg
struct is used by iproute2 for all generic dump requests - links,
addresses, routes and rules when it is really only valid for link
requests.
There is 1 is example where the kernel deals with the wrong struct: link
dumps after VF support was added. Older iproute2 was sending rtgenmsg as
the header instead of ifinfomsg so a patch was added to try and detect
old userspace vs new:
e5eca6d41f53 ("rtnetlink: fix userspace API breakage for iproute2 < v3.9.0")
The latest example is Christian's patch set wanting to return addresses for
a target namespace. It guesses the header struct is an ifaddrmsg and if it
guesses wrong a netlink warning is generated in the kernel log on every
address dump which is unacceptable.
Another example where the kernel is a bit lenient is route dumps: iproute2
can send either a request with either ifinfomsg or a rtmsg as the header
struct, yet the kernel always treats the header as an rtmsg (see
inet_dump_fib and rtm_flags check). The header inconsistency impacts the
ability to add kernel side filters for route dumps - a necessary feature
for scale setups with 100k+ routes.
How to resolve the problem of not breaking old userspace yet be able to
move forward with new features such as kernel side filtering which are
crucial for efficient operation at high scale?
This patch set addresses the problem by adding a new netlink flag,
NLM_F_DUMP_PROPER_HDR, that userspace can set to say "I have a clue, and
I am sending the right header struct" and that the struct fields and any
attributes after it should be used for filtering the data returned in the
dump.
Kernel side, the dump handlers are updated to verify the message contains
at least the expected header struct:
RTM_GETLINK: ifinfomsg
RTM_GETADDR: ifaddrmsg
RTM_GETMULTICAST: ifaddrmsg
RTM_GETANYCAST: ifaddrmsg
RTM_GETADDRLABEL: ifaddrlblmsg
RTM_GETROUTE: rtmsg
RTM_GETSTATS: if_stats_msg
RTM_GETNEIGH: ndmsg
RTM_GETNEIGHTBL: ndtmsg
RTM_GETNSID: rtnl_net_dumpid
RTM_GETRULE: fib_rule_hdr
RTM_GETNETCONF: netconfmsg
RTM_GETMDB: br_port_msg
And then every field in the header struct should be 0 with the exception
of the family. There are a few exceptions to this rule where the kernel
already influences the data returned by values in the struct. Next the
message should not contain attributes unless the kernel implements
filtering for it. Any unexpected data causes the dump to fail with EINVAL.
If the new flag is honored by the kernel and the dump contents adjusted
by any data passed in the request, the dump handler can set the
NLM_F_DUMP_FILTERED flag in the netlink message header.
As an example of how this new NLM_F_DUMP_PROPER_HDR can be leveraged,
the last 6 patch add filtering of route dumps based on table id, protocol,
tos, flags, scope, and egress device.
David Ahern (25):
net/netlink: Pass extack to dump callbacks
net/ipv6: Refactor address dump to push inet6_fill_args to
in6_dump_addrs
netlink: introduce NLM_F_DUMP_PROPER_HDR flag
net/ipv4: Update inet_dump_ifaddr to support NLM_F_DUMP_PROPER_HDR
net/ipv6: Update inet6_dump_addr to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update rtnl_dump_ifinfo to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update rtnl_bridge_getlink to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update rtnl_stats_dump to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update inet6_dump_ifinfo to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update ipmr_rtm_dumplink to support NLM_F_DUMP_PROPER_HDR
rtnetlink: Update fib dumps to support NLM_F_DUMP_PROPER_HDR
net/neigh: Refactor dump filter handling
net/neighbor: Update neigh_dump_info to support NLM_F_DUMP_PROPER_HDR
net/neighbor: Update neightbl_dump_info to support
NLM_F_DUMP_PROPER_HDR
net/namespace: Update rtnl_net_dumpid to support NLM_F_DUMP_PROPER_HDR
net/fib_rules: Update fib_nl_dumprule to support NLM_F_DUMP_PROPER_HDR
net/ipv6: Update ip6addrlbl_dump to support NLM_F_DUMP_PROPER_HDR
net: Update netconf dump handlers to support NLM_F_DUMP_PROPER_HDR
net/bridge: Update br_mdb_dump to support NLM_F_DUMP_PROPER_HDR
net: Add struct for fib dump filter
net/ipv4: Plumb support for filtering route dumps
net/ipv6: Plumb support for filtering route dumps
net/mpls: Plumb support for filtering route dumps
net: Plumb support for filtering ipv4 and ipv6 multicast route dumps
net: Enable kernel side filtering of route dumps
include/linux/mroute_base.h | 5 +-
include/linux/netlink.h | 2 +
include/net/ip6_route.h | 1 +
include/net/ip_fib.h | 16 +++-
include/uapi/linux/netlink.h | 1 +
net/bridge/br_mdb.c | 20 ++++-
net/core/fib_rules.c | 25 +++++-
net/core/neighbour.c | 136 +++++++++++++++++++++++--------
net/core/net_namespace.c | 8 ++
net/core/rtnetlink.c | 185 +++++++++++++++++++++++++++++++++----------
net/ipv4/devinet.c | 74 +++++++++++++----
net/ipv4/fib_frontend.c | 76 +++++++++++++++++-
net/ipv4/fib_trie.c | 33 +++++---
net/ipv4/ipmr.c | 44 +++++++++-
net/ipv4/ipmr_base.c | 42 +++++++++-
net/ipv6/addrconf.c | 160 ++++++++++++++++++++++++++++---------
net/ipv6/addrlabel.c | 25 +++++-
net/ipv6/ip6_fib.c | 23 +++++-
net/ipv6/ip6mr.c | 12 ++-
net/ipv6/route.c | 36 ++++++---
net/mpls/af_mpls.c | 82 ++++++++++++++++++-
net/netlink/af_netlink.c | 20 +++--
22 files changed, 860 insertions(+), 166 deletions(-)
--
2.11.0
next reply other threads:[~2018-10-02 7:09 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-02 0:28 David Ahern [this message]
2018-10-02 0:28 ` [PATCH RFC v2 net-next 01/25] net/netlink: Pass extack to dump callbacks David Ahern
2018-10-02 11:07 ` Christian Brauner
2018-10-02 0:28 ` [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_dump_addrs David Ahern
2018-10-02 10:54 ` Jiri Benc
2018-10-02 11:03 ` Christian Brauner
2018-10-02 11:07 ` Jiri Benc
2018-10-02 11:09 ` Christian Brauner
2018-10-02 15:11 ` David Ahern
2018-10-02 16:24 ` Jiri Benc
2018-10-02 0:28 ` [PATCH RFC v2 net-next 03/25] netlink: introduce NLM_F_DUMP_PROPER_HDR flag David Ahern
2018-10-02 11:06 ` Jiri Benc
2018-10-02 11:18 ` Christian Brauner
2018-10-02 11:27 ` Jiri Benc
2018-10-02 14:57 ` David Ahern
2018-10-02 16:30 ` Jiri Benc
2018-10-02 19:20 ` David Ahern
2018-10-02 14:55 ` David Ahern
2018-10-02 16:33 ` Jiri Benc
2018-10-02 0:28 ` [PATCH RFC v2 net-next 04/25] net/ipv4: Update inet_dump_ifaddr to support NLM_F_DUMP_PROPER_HDR David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 05/25] net/ipv6: Update inet6_dump_addr " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 06/25] rtnetlink: Update rtnl_dump_ifinfo " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 07/25] rtnetlink: Update rtnl_bridge_getlink " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 08/25] rtnetlink: Update rtnl_stats_dump " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 09/25] rtnetlink: Update inet6_dump_ifinfo " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 10/25] rtnetlink: Update ipmr_rtm_dumplink " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 11/25] rtnetlink: Update fib dumps " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 12/25] net/neigh: Refactor dump filter handling David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 13/25] net/neighbor: Update neigh_dump_info to support NLM_F_DUMP_PROPER_HDR David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 14/25] net/neighbor: Update neightbl_dump_info " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 15/25] net/namespace: Update rtnl_net_dumpid " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 16/25] net/fib_rules: Update fib_nl_dumprule " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 17/25] net/ipv6: Update ip6addrlbl_dump " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 18/25] net: Update netconf dump handlers " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 19/25] net/bridge: Update br_mdb_dump " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 20/25] net: Add struct for fib dump filter David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 21/25] net/ipv4: Plumb support for filtering route dumps David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 22/25] net/ipv6: " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 23/25] net/mpls: " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 24/25] net: Plumb support for filtering ipv4 and ipv6 multicast " David Ahern
2018-10-02 0:28 ` [PATCH RFC v2 net-next 25/25] net: Enable kernel side filtering of " David Ahern
2018-10-03 14:59 ` [PATCH RFC v2 net-next 00/25] rtnetlink: Add support for rigid checking of data in dump request Stephen Hemminger
2018-10-03 15:21 ` David Ahern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181002002851.5002-1-dsahern@kernel.org \
--to=dsahern@kernel.org \
--cc=christian@brauner.io \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=jbenc@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.