netdev - Re: [PATCH net-next 1/1] net_sched: Introduce skbmod action

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: <578E00BB.1050806@mojatatu.com>
Date:	Tue, 19 Jul 2016 06:28:11 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Cong Wang <xiyou.wangcong@...il.com>
Cc:	Thomas Graf <tgraf@...g.ch>,
	Daniel Borkmann <daniel@...earbox.net>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	David Miller <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Subject: Re: [PATCH net-next 1/1] net_sched: Introduce skbmod action

On 16-07-18 01:38 PM, Cong Wang wrote:
> On Mon, Jul 18, 2016 at 3:26 AM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
>> On 16-07-18 06:07 AM, Thomas Graf wrote:
>>
>>>
>>> Right. I was at the same point as Jamal and it is nasty to try and
>>> reverse engineer the dumps without any further hints. I assume that's
>>> what he is referring to with difficulties.
>>>
>>
>> That +: if you get me a field which says "dstmac" i dont have to go
>> and start aggregating 32bit chunks to create a 48bit MAC (or worse
>> look at the offset and figure where they come from).
>>
>
> Been there, done that. I debugged u32 filter dumps too, I understand
> your concern.
>
> But this still looks like solvable to me, although it is definitely not easy,
> probably even harder than the parsing logic. I will try to write some
> code for iproute2 to see how far I can go.
>

I am sure that will be useful for someone - just not me.

> Adding a new type of action/filter in kernel just for convenience seems
> overkill. At very least I think we should just extend the existing ones,
> for example, allowing pedit to accept and dump DST_MAC etc. Does this
> sound good to you?
>

Not for me Cong - but i have no doubt it would improve pedit's
usability. Besides that is fixing one app (tc).
What i am trying to do is a common use case. It is an
optimization that has become necessary; your effort could be parallel
to this. Look at how much time we are spending arm chair lawyering this;
please go ahead and do that with iproute2 and let this patch go in. Like
I said this comes from deployment experience and need.

cheers,
jamal