netdev - Re: fib_rules: Resolve goto rules target on delete

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]

Message-ID: <11d8ff28-a667-8d2d-9b90-304ee76ee94a@gmail.com>
Date:   Wed, 21 Jun 2017 10:44:47 +0300
From:   Serhey Popovych <serhe.popovych@...il.com>
To:     netdev@...r.kernel.org
Subject: Re: fib_rules: Resolve goto rules target on delete


> From: Serhey Popovych <serhe.popovych@...il.com>
> Date: Fri, 16 Jun 2017 15:44:47 +0300
> 
>> We should avoid marking goto rules unresolved when their
>> target is actually reachable after rule deletion.
>>
>> Consolder following sample scenario:
>>
>>   # ip -4 ru sh
>>   0:      from all lookup local
>>   32000:  from all goto 32100
>>   32100:  from all lookup main
>>   32100:  from all lookup default
>>   32766:  from all lookup main
>>   32767:  from all lookup default
>>
>>   # ip -4 ru del pref 32100 table main
>>   # ip -4 ru sh
>>   0:      from all lookup local
>>   32000:  from all goto 32100 [unresolved]
>>   32100:  from all lookup default
>>   32766:  from all lookup main
>>   32767:  from all lookup default
>>
>> After removal of first rule with preference 32100 we
>> mark all goto rules as unreachable, even when rule with
>> same preference as removed one still present.
>>
>> Check if next rule with same preference is available
>> and make all rules with goto action pointing to it.
>>
>> Signed-off-by: Serhey Popovych <serhe.popovych@...il.com>
> 
> Applied, thanks.
> 
> It would be awesome if you could distill the above into a test case that
> could be run under tools/testing/selftests/networking.
Yes, I already think about testing too.

Actually I have series of  patches to improve fib_rules support both in
core and per protocol (merge suppress, callback, reduce per network
namespace memory consumption - useful for docker setups, more precise
validation of netlink configuration messages, additional matching
facilities etc) so testing is  definitely required before my changes
went upstream!

About testing implementation: I see there is no infrastructure
to test netlink based configuration in tools/testing. How to make
this better? Use libnl, write scripts that use iproute2 utilities?
Where I can get additional to Documentation/kselftest.txt information?

> 
> Thanks!
> 

-- 
Thanks, Serhey