netdev - Re: [PATCH net v4 1/8] ipv4/fib_frontend: Rename ip_valid_fib_dump

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 17 Jun 2019 20:28:30 +0200
From:   Stefano Brivio <sbrivio@...hat.com>
To:     David Ahern <dsahern@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Martin KaFai Lau <kafai@...com>,
        Jianlin Shi <jishi@...hat.com>, Wei Wang <weiwan@...gle.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        netdev@...r.kernel.org
Subject: Re: [PATCH net v4 1/8] ipv4/fib_frontend: Rename
 ip_valid_fib_dump_req, provide non-strict version

On Mon, 17 Jun 2019 11:06:51 -0600
David Ahern <dsahern@...il.com> wrote:

> On 6/17/19 8:13 AM, Stefano Brivio wrote:
> >>
> >> With strict checking (5.0 and forward):
> >> - RTM_F_CLONED NOT set means dump only FIB entries
> >> - RTM_F_CLONED set means dump only exceptions  
> > 
> > Okay. Should we really ignore the RFC and NLM_F_MATCH though? If we add
> > field(s) to the filter, it comes almost for free, something like:
> > 
> > 	if (nlh->nlmsg_flags & NLM_F_MATCH)
> > 		filter->dump_exceptions = rtm->rtm_flags & RTM_F_CLONED;
> > 
> > instead of:
> > 
> > 	filter->dump_exceptions = rtm->rtm_flags & RTM_F_CLONED;  
> 
> This is where you keep losing me. iproute2 has always set NLM_F_MATCH on
> dump requests, so that flag can not be used as a discriminator here.

iproute2 yes, but some other users (I'm not aware of any so I have no
examples) might *very* vaguely follow the RFC and expect consistent
results. That was my only point here. Most likely just a theoretical
one.

> >   
> >> Without strict checking (old iproute2 on any kernel):
> >> - dump all, userspace has to sort
> >>
> >> Kernel side this can be handled with new field, dump_exceptions, in the
> >> filter that defaults to true and then is reset in the strict path if the
> >> flag is not set.  
> > 
> > I guess we need to add two fields, we'll need a 'dump_routes' too.
> > 
> > Otherwise, the dump functions can't distinguish between the three cases
> > ('no strict checking', 'strict checking and RTM_F_CLONED', 'strict
> > checking and no RTM_F_CLONED'). How would you do this with a single
> > additional field?
> >   
> 
> sure, separate fields are needed for the pre-strict mode use case.

Well, they are needed, in general. They both start as true, non-strict
mode doesn't clear them, strict mode clears one. That's how I would do
it.

> So, I take it we are converging on this:
> 
> 1. non-strict mode, dump both (FIB entries and exceptions). Userspace
> has to filter. This is the legacy behavior you are trying to restore.
> 
> 2. strict mode:
>    a. dump only FIB entries if RTM_F_CLONED is not set
>    b. dump only exception entries if RTM_F_CLONED is set
> 
> Agreed?

Agreed in general, maybe let me know what you think about the
NLM_F_MATCH point above though.

-- 
Stefano