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
| ||
|
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.
Powered by blists - more mailing lists