netdev - Re: [PATCH bpf-next] bpf: don't check against device MTU in __bpf_skb_max

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: <CANP3RGf581mZKE2Eky-bY6swU6TAFv1vzxxZ24SQ+yB9TGAD8w@mail.gmail.com>
Date:   Tue, 15 Sep 2020 17:12:59 -0700
From:   Maciej Żenczykowski <maze@...gle.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Jesper Dangaard Brouer <brouer@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>, bpf <bpf@...r.kernel.org>,
        Linux NetDev <netdev@...r.kernel.org>,
        Daniel Borkmann <borkmann@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        John Fastabend <john.fastabend@...il.com>
Subject: Re: [PATCH bpf-next] bpf: don't check against device MTU in __bpf_skb_max_len

On Tue, Sep 15, 2020 at 1:47 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> [ just jumping in to answer this bit: ]
>
> > Would you happen to know what ebpf startup overhead is?
> > How big a problem is having two (or more) back to back tc programs
> > instead of one?
>
> With a jit'ed BPF program and the in-kernel dispatcher code (which
> avoids indirect calls), it's quite close to a native function call.

Hmm, I know we have (had? they're upstream now I think) some CFI vs
BPF interaction issues.
We needed to mark the BPF call into JIT'ed code as CFI exempt.

CFI is Code Flow Integrity and is some compiler magic, to quote wikipedia:
Google has shipped Android with the Linux kernel compiled by Clang
with link-time optimization (LTO) and CFI since 2018.[12]
I don't know much more about it.

But we do BPF_JIT_ALWAYS_ON on 64-bit kernels, so it sounds like we
might be good.

> > We're running into both verifier performance scaling problems and code
> > ownership issues with large programs...
> >
> > [btw. I understand for XDP we could only use 1 program anyway...]
>
> Working on that! See my talk at LPC:
> https://linuxplumbersconf.org/event/7/contributions/671/

Yes, I'm aware and excited about it!

Unfortunately, Android S will only support 4.19, 5.4 and 5.10 for
newly launched devices (and 4.9/4.14 for upgrades).
(5.10 here means 'whatever is the next 5.x LTS', but that's most likely 5.10)
I don't (yet) even have real phone hardware running 5.4, and 5.10
within the next year is even more of a stretch.

> Will post a follow-up to the list once the freplace multi-attach series
> lands.