netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: David Ahern <dsahern@gmail.com>
Cc: David Miller <davem@davemloft.net>,
	Martin KaFai Lau <kafai@fb.com>, Jianlin Shi <jishi@redhat.com>,
	Wei Wang <weiwan@google.com>, Eric Dumazet <edumazet@google.com>,
	Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net v4 1/8] ipv4/fib_frontend: Rename ip_valid_fib_dump_req, provide non-strict version
Date: Sat, 15 Jun 2019 05:27:05 +0200	[thread overview]
Message-ID: <20190615052705.66f3fe62@redhat.com> (raw)
In-Reply-To: <d780b664-bdbd-801f-7c61-d4854ff26192@gmail.com>

On Fri, 14 Jun 2019 21:16:54 -0600
David Ahern <dsahern@gmail.com> wrote:

> On 6/14/19 9:13 PM, Stefano Brivio wrote:
> > On Fri, 14 Jun 2019 20:54:49 -0600
> > David Ahern <dsahern@gmail.com> wrote:
> >   
> >> On 6/14/19 7:32 PM, Stefano Brivio wrote:  
> >>> ip_valid_fib_dump_req() does two things: performs strict checking on
> >>> netlink attributes for dump requests, and sets a dump filter if netlink
> >>> attributes require it.
> >>>
> >>> We might want to just set a filter, without performing strict validation.
> >>>
> >>> Rename it to ip_filter_fib_dump_req(), and add a 'strict' boolean
> >>> argument that must be set if strict validation is requested.
> >>>
> >>> This patch doesn't introduce any functional changes.
> >>>
> >>> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> >>> ---
> >>> v4: New patch
> >>>     
> >>
> >> Can you explain why this patch is needed? The existing function requires
> >> strict mode and is needed to enable any of the kernel side filtering
> >> beyond the RTM_F_CLONED setting in rtm_flags.  
> > 
> > It's mostly to have proper NLM_F_MATCH support. Let's pick an iproute2
> > version without strict checking support (< 5.0), that sets NLM_F_MATCH
> > though. Then we need this check:
> > 
> > 	if (nlh->nlmsg_len < nlmsg_msg_size(sizeof(*rtm)))  
> 
> but that check existed long before any of the strict checking and kernel
> side filtering was added.

Indeed. And now I'm recycling it, even if strict checking is not
requested.

> > and to set filter parameters not just based on flags (i.e. RTM_F_CLONED),
> > but also on table, protocol, etc.  
> 
> and to do that you *must* have strict checking. There is no way to trust
> userspace without that strict flag set because iproute2 for the longest
> time sent the wrong header for almost all dump requests.

So you're implying that:

- we shouldn't support NLM_F_MATCH

- we should keep this broken for iproute2 < 5.0.0?

I guess this might be acceptable, but please state it clearly.

By the way, if really needed, we can do strict checking even if not
requested. But this might add more and more userspace breakage, I guess.

-- 
Stefano

  reply	other threads:[~2019-06-15  3:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-15  1:32 [PATCH net v4 0/8] Fix listing (IPv4, IPv6) and flushing (IPv6) of cached route exceptions Stefano Brivio
2019-06-15  1:32 ` [PATCH net v4 1/8] ipv4/fib_frontend: Rename ip_valid_fib_dump_req, provide non-strict version Stefano Brivio
2019-06-15  2:54   ` David Ahern
2019-06-15  3:13     ` Stefano Brivio
2019-06-15  3:16       ` David Ahern
2019-06-15  3:27         ` Stefano Brivio [this message]
2019-06-16 20:04           ` Stefano Brivio
2019-06-17 13:38             ` David Ahern
2019-06-17 14:13               ` Stefano Brivio
2019-06-17 17:06                 ` David Ahern
2019-06-17 18:28                   ` Stefano Brivio
2019-06-17 13:18           ` David Ahern
2019-06-15  1:32 ` [PATCH net v4 2/8] ipv4: Honour NLM_F_MATCH, make semantics of NETLINK_GET_STRICT_CHK consistent Stefano Brivio
2019-06-15  3:13   ` David Ahern
2019-06-15  3:23     ` Stefano Brivio
2019-06-17 13:29       ` David Ahern
2019-06-15  1:32 ` [PATCH net v4 3/8] ipv4/fib_frontend: Allow RTM_F_CLONED flag to be used for filtering Stefano Brivio
2019-06-15  1:32 ` [PATCH 4/8] ipv4: Dump routed caches if requested Stefano Brivio
2019-06-15  1:32 ` [PATCH 5/8] Revert "net/ipv6: Bail early if user only wants cloned entries" Stefano Brivio
2019-06-15  1:32 ` [PATCH 6/8] ipv6: Honour NLM_F_MATCH, make semantics of NETLINK_GET_STRICT_CHK consistent Stefano Brivio
2019-06-15  1:32 ` [PATCH 7/8] ipv6: Dump route exceptions too in rt6_dump_route() Stefano Brivio
2019-06-15  1:32 ` [PATCH 8/8] ip6_fib: Don't discard nodes with valid routing information in fib6_locate_1() Stefano Brivio

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=20190615052705.66f3fe62@redhat.com \
    --to=sbrivio@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=edumazet@google.com \
    --cc=jishi@redhat.com \
    --cc=kafai@fb.com \
    --cc=matti.vaittinen@fi.rohmeurope.com \
    --cc=netdev@vger.kernel.org \
    --cc=weiwan@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).