netdev - [Q/RFC] BPF use in broader scope

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

Date:	Thu, 29 Mar 2012 09:44:43 +0200
From:	Jiri Pirko <jpirko@...hat.com>
To:	netdev@...r.kernel.org
Cc:	eric.dumazet@...il.com, davem@...emloft.net,
	bhutchings@...arflare.com, shemminger@...tta.com
Subject: [Q/RFC] BPF use in broader scope

Hi all.

I came to an idea of using BPF infrastructure currently used in kernel,
for computing hashes selecting TX ports in team device. Since the same
data (skb) are alalyzed/used as for socket filtering, BPF seems so be quite
suitable for this. It would allow userspace daemon to specify various
kinds of TX selection algorithms.

Here are proposed things to be done:
1) introduce in-kernel api for creating sk-unattached filters (I have
   the patch cooked up already)

2) extend current BPF machine to allow XOR operation. Not sure if this
   is doable or what the best of doing this is.

3) add possibility to pass some data to the machine via
   pre-filling "Scratch Memory Store". I think this can be done easily
   moving "u32 mem[BPF_MEMWORDS];" to bpf_func caller and pass it as the
   second function parameter. That should not break anything.

Then the computed hash can be either stored into Scratch memory or returned
directly (where ordinary sk filters return len).

Does this seems reasonable? Thoughts, comments?

Thanks!

Jirka

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html