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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ