All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
	David Ahern <dsahern@kernel.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
	christian@brauner.io, jbenc@redhat.com
Subject: Re: [PATCH RFC v2 net-next 00/25] rtnetlink: Add support for rigid checking of data in dump request
Date: Wed, 3 Oct 2018 09:21:15 -0600	[thread overview]
Message-ID: <953ee3e1-d305-4058-bf2d-4e56268bccd1@gmail.com> (raw)
In-Reply-To: <20181003075909.4d977567@xeon-e3>

On 10/3/18 8:59 AM, Stephen Hemminger wrote:
> On Mon,  1 Oct 2018 17:28:26 -0700
> David Ahern <dsahern@kernel.org> wrote:
> 
>> 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?
> 
> What about forward compatibility? How would this work when running new iproute2
> command on older kernels?
> 
> I expect the new command would set the "I am smart flag" and the older
> kernel would ignore it. The if the header for the message type had
> changed, the dump would be broken.
> 

The kernel today happily ignores garbage in the request it does not
understand. If the new iproute2 sends a dump request with attributes or
fields in the header set the kernel ignores it.

With the setsockopt option for setting the flag, userspace knows the
kernel does not support attribute checking and kernel side filtering.

As far as changing the header (new iproute2 on old kernel), there are 3
dumps that look at the header beyond the family:
1. link dumps - but it has the expected ifinfomsg header

2. neighbor dumps (expects the right ndmsg header)

3. fdb dumps - wrongly expect ifinfomsg header but there is patch to
detect when the ndmsg header is sent (ip neigh vs bridge fdb)

The 4th dump that looks at the header is addresses. Those patches were
added in this development cycle. Those dumps need to be wrapped in the
'userspace has a clue' setting or reverted until this is figured out.

      reply	other threads:[~2018-10-03 22:10 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-02  0:28 [PATCH RFC v2 net-next 00/25] rtnetlink: Add support for rigid checking of data in dump request David Ahern
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 [this message]

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=953ee3e1-d305-4058-bf2d-4e56268bccd1@gmail.com \
    --to=dsahern@gmail.com \
    --cc=christian@brauner.io \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --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.