netdev - Re: [PATCH v5 net-next 1/3] net: flow_dissector: avoid multiple calls in BPF

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:	Tue, 20 May 2014 11:58:59 +0200
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Chema Gonzalez <chema@...gle.com>
CC:	Alexei Starovoitov <ast@...mgrid.com>,
	David Miller <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH v5 net-next 1/3] net: flow_dissector: avoid multiple calls
 in BPF

On 05/20/2014 12:23 AM, Chema Gonzalez wrote:
> On Fri, May 16, 2014 at 3:00 PM, Alexei Starovoitov <ast@...mgrid.com> wrote:
...
>> Other than design issue there is technical problem too.
>> You're not updating eBPF JIT and context->flow_initted will have junk,
>> so ld_poff will be returning junk too.
>> JITs and interpreter must match. That was always the case even in
>> old days of classic BPF. Interpreter initialized A and X to zero,
>> JITs had to do the same. If you add stuff like this to interpreter,
>> JITs would have to follow. Fast forward few years and this is not scalable.
>> You have several JITs around and adding custom stuff to interpreter
>> may not even be possible to do in JITs.
> This is a fair point. In fact my patch is breaking "ld poff."
>
> I think the previous mechanism where a new insn added to BPF would
> cause the BPF JIT engine to refuse to run was a more scalable: New
> stuff always went in the non-jitted runner, and people interested in
> the jitted version will port when they needed it. We definitely not
> want to require people adding new features to provide 6 versions of
> the code.

Absolutely, "we definitely not want to require people adding new features
to provide 6 versions of the code". I agree with this statement and that
is exactly one of the goals of the new BPF mechanism. You might have seen
how the internal conversion function performs this task for all current
BPF extensions, and that is exactly so that JITs, once they are in place,
do not need to be upgraded 6 times anymore (in contrast to your previous
statement -- as people who want to use one of the extensions, needed to
port them to each of their arch-specific JITs before).

Best,

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