netdev - Re: [PATCH v3 net-next 2/2] tc: add 'needs

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, 09 Apr 2015 17:38:22 +0200
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Jamal Hadi Salim <jhs@...atatu.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	David Miller <davem@...emloft.net>
CC:	tgraf@...g.ch, jiri@...nulli.us, netdev@...r.kernel.org
Subject: Re: [PATCH v3 net-next 2/2] tc: add 'needs_l2' flag to ingress qdisc

On 04/09/2015 12:49 PM, Jamal Hadi Salim wrote:
...
> Your changes penalize everyone else because of this assumption
> bpf makes. We have always tried to be sensitive to perfomance.

That includes also BPF, right? ;) I mean you'd need to push extra
unneeded per-packet instructions down into the interpreter and
JITs that neither the output path needs in case of {cls,act}_bpf,
and generally other users working on skbs such as team driver, all
possible kind of sockets with filters attached, xt_bpf, etc, etc
just to accommodate for the ingress use-case. I mean I understand
your concern, but making BPF cls/act responsible for that knowledge
has it's downsides just as well.

Moreover, we'd enforce user space to start programming with
unintuitive negative offsets when accessing mac layer, and cls_bpf
at least, since it's around for some time, would need to start
differentiating between classic and native eBPF to keep compat
with old BPF programs for the output path. That's pretty messy. :/
--
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