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: <578CAEB8.9070805@mojatatu.com>
Date:	Mon, 18 Jul 2016 06:26:00 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Thomas Graf <tgraf@...g.ch>, Daniel Borkmann <daniel@...earbox.net>
Cc:	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	davem@...emloft.net, netdev@...r.kernel.org,
	xiyou.wangcong@...il.com, nikolay@...ulusnetworks.com
Subject: Re: [PATCH net-next 1/1] net_sched: Introduce skbmod action

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).

> Looking back, I would simply calculate a SHA hash over the original
> filter in text form, pass the hash together with the tc filter and then
> associate the hash with the filter text stored in user space. This
> would not only benefit pedit but also u32 and possibly others.
>

A "cookie" tag that is sent to the kernel would serve the purpose.
We would need to standardize what the meaning of such a cookie is.

> It also has the advantage that extending the kernel once now will allow
> to add additional higher level abstractions later on without requiring
> users to rebase their kernels.
>

Yes - and btw it works well with hardware offloads. It is a good free
form "assembler" level. But i dont think it serves well when we have
known often-used cases such as these.
It is like doing tcp over raw sockets - at some point it becomes more
efficient and more usable to just introduce tcp sockets. Thats all I
am asking for.

cheers,
jamal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ