netdev - Re: [iproute PATCH 3/3] tc: pedit: Fix retain value for ihl adjustments

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <56DD642D.8010401@mojatatu.com>
Date:	Mon, 7 Mar 2016 06:21:17 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Phil Sutter <phil@....cc>,
	Stephen Hemminger <shemming@...cade.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [iproute PATCH 3/3] tc: pedit: Fix retain value for ihl
 adjustments

On 16-03-03 09:32 AM, Phil Sutter wrote:
> Hi,
>

>
>> The patches look good to me. Phil, maybe get rid of that comment at the
>> top which was worrying about endianness. I think you fixed it.
>
> I'm not so sure. The kernel explicitly takes care to get the bit
> ordering right:
>
[..]
> act_pedit though just mangles the whole byte as-is, and if that was
> correct, we would not have to go that extra mile in struct iphdr, or do
> we?
>

I meant in general - the note to say that there are endianes issues
should go.


>> These would of course require more of a larger setup to vet
>> and running tcpdump to check the correct bytes are being
>> modified.
>

Indeed - That is how i normally would test. It is more complex.
Your scheme is good - but will not catch a kernel bug.

> Since I am lazy, I wanted to have as much automation as possible while
> testing. Therefore I just assumed that act_pedit does the right thing
> all the time,

famous last words ;->

> and iproute just has to feed it correct values. Given the
> scope of this patch, this is also completely sufficient. Of course, the
> tests/ directory would benefit more from a full test. But since
> automation then becomes tricky, I'm not sure it makes much sense to
> deliberately write code for that.
>

Your test is still useful and i think should go into the tests dir.

cheers,
jamal

> Thanks for the review,
>
> Phil
>