netdev - Re: [PATCH iproute2 -next] tc, bpf: finalize eBPF support for cls and act front-end

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]

Date:	Thu, 02 Apr 2015 13:30:55 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Daniel Borkmann <daniel@...earbox.net>, stephen@...workplumber.org
Cc:	ast@...mgrid.com, jiri@...nulli.us, tgraf@...g.ch,
	netdev@...r.kernel.org, Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [PATCH iproute2 -next] tc,
 bpf: finalize eBPF support for cls and act front-end

On Thu, Apr 2, 2015, at 12:19, Daniel Borkmann wrote:
> On 04/02/2015 02:29 AM, Hannes Frederic Sowa wrote:
> > On Thu, Apr 2, 2015, at 02:24, Daniel Borkmann wrote:
> >> On 04/02/2015 02:13 AM, Hannes Frederic Sowa wrote:
> >> ...
> >>> Maybe a small utility programs like:
> >>>
> >>> bpf (--lookup|--update|--delete|--get-next-key) -fd
> >>> filedescriptor-number (type conversion parameters here) key [value]
> >>>
> >>> So it can be easily used by shell scripts.
> >>>
> >>> For that the filedescriptor numbers would need to be exported (already
> >>> opened) into a spawned shell and the numbers could be specified either
> >>> in environment or just by printing text which can be sourced by shells
> >>> (we already talked about the maybe exec 5</proc/pid/fd/1234 idea). Seems
> >>> this can be just build ontop this current patch by extending the
> >>> bpf-agent you already build, no?
> >>
> >> I was thinking about that and trying it out, but as far as I can tell,
> >> due to the anon inodes that are currently underlying as the fd provider,
> >> it doesn't work w/o larger kernel changes. So, the file descriptor
> >> passing
> >> is currently the only way to transfer control.
> >
> > Does receiving them via af_unix and spawning a new shell with the fds
> > already open work?
> 
> I'm probably missing something, would that need changes to bash?
> 
> I mean exec could bind an fd in the shell to sockets and use that,
> for example ...
> 
>    exec 3<>/dev/tcp/www.slashdot.org/80
>    echo -e "GET / HTTP/1.1\r\nhost:
>    http://www.slashdot.org\r\nConnection: close\r\n\r\n" >&3
>    cat <&3
> 
> ... perhaps such a built-in fake device for retrieving bpf map fds
> might be interesting, e.g. exec 4<>/dev/bpf/<obj-file>/<map-name> if
> that has been given to bash?
> 
> Anyway, I think to have some utility for shell scripts, as you
> suggest, certainly sounds interesting!

All file descriptors will be inherited by exec as long as the O_CLOEXEC
flag wasn't specified on them. So you can retrieve the fds via af_unix
and just exec a new shell. The file descriptors will stay open and you
can pass the numbers of the fds via environment. This wouldn't need
changes to bash or kernel.

Does that make sense?

Thanks,
Hannes
--
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