netdev - Re: [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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAgcAh0QbHoi0VfFfTC1RLfzm2AbXBD1WmEQ2-958vQ0R=MXsA@mail.gmail.com>
Date:	Thu, 29 Mar 2012 15:04:29 +0100
From:	Nuno Martins <nuno.martins@...xamagica.pt>
To:	Jiri Pirko <jpirko@...hat.com>
Cc:	netdev@...r.kernel.org, eric.dumazet@...il.com,
	davem@...emloft.net, bhutchings@...arflare.com,
	shemminger@...tta.com, Alfredo Matos <alfredo.matos@...xamagica.pt>
Subject: Re: [Q/RFC] BPF use in broader scope

On Thu, Mar 29, 2012 at 8:44 AM, Jiri Pirko <jpirko@...hat.com> wrote:
> 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?
>

Hi all,

I've also been working on mechanism that requires creating custom BFP
filters, but for PID based packet filtering. It allows attaching
custom filters to a
socket, through setsocketopt, making it possible to detect when packets belongs
 to a target process id (previously identified through kprobes).

The in-kernel api we use, enables registering and unregistering filter
functions,
 which are then stored on a filter function list.

When attaching the custom filter function, it replaces the current
filter, releasing the JIT code if necessary. However, the newly
attached filter function does not get JIT compiled (bpf_jit_compile)
to allow custom functions without having to provide the corresponding
ASM code.

Using the JIT extensions that Jirka mentions in step 3 could also allows to
compile custom.

We are in the process of making the source code available through a
project page dedicated to PID monitoring, and will (hopefully) send a
Q/RFC to this list tomorrow.

> Thanks!

Thanks.

>
> Jirka
>

Nuno Martins

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