netdev - Re: [PATCHv2] net: bpf: reject invalid shifts

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]

Date:	Tue, 12 Jan 2016 18:24:16 -0800
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Daniel Borkmann <daniel@...earbox.net>,
	Rabin Vincent <rabin@....in>, davem@...emloft.net,
	netdev@...r.kernel.org, ast@...nel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCHv2] net: bpf: reject invalid shifts

On Tue, Jan 12, 2016 at 06:11:38PM -0800, Eric Dumazet wrote:
> On Tue, 2016-01-12 at 15:47 -0800, Alexei Starovoitov wrote:
> 
> > I would agree if those loaded programs would do something sensible,
> > but they're broken. As shown arm and arm64 would execute them
> > differently without JIT, because HW treats such shifts differently.
> > I also checked that libpcap is sane and doesn't generate broken shifts.
> > imo we're not breaking backward compatiblity here.
> > 
> 
> How did you prove a particular code path was even taken in a BPF
> program ? This is new to me.

Simple. I only found absolute constants for shift instructions
in libpcap source.

> As I said, it is possible some guys never noticed their BPF program were
> 'broken' because this invalid shift was hidden in a dead code part.
> 
> So a program might appear as 'weak' when in fact its behavior was
> absolutely correct.
> 
> You assume everybody uses libpcap, this is wrong, and for very obvious
> reasons.

I didn't imply that.
Obviously there is chromium, libsecomp, lxd, dhclient, nmap and tons
of other apps. The point was for the library the most frequently
associated with classic bpf.

I think adding pr_err_once() to bpf_check_classic() as you
suggested makes the most sense to me at this point.
If anyone wants to submit a patch that masks K &= 31, I would ok with
it as well, but imo it's a disservice to classic bpf users.
Leaving it as-is and waiting for other jits to blow up is not an option.