netdev - Re: bpf memory model. Was: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin

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]

Message-ID: <20190130195000.aswpdngpvtfyylng@ast-mbp.dhcp.thefacebook.com>
Date:   Wed, 30 Jan 2019 11:50:02 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Will Deacon <will.deacon@....com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Alexei Starovoitov <ast@...nel.org>, davem@...emloft.net,
        daniel@...earbox.net, jakub.kicinski@...ronome.com,
        netdev@...r.kernel.org, kernel-team@...com, mingo@...hat.com,
        Paul McKenney <paulmck@...ux.vnet.ibm.com>, jannh@...gle.com
Subject: Re: bpf memory model. Was: [PATCH v4 bpf-next 1/9] bpf: introduce
 bpf_spin_lock

On Wed, Jan 30, 2019 at 06:11:00PM +0000, Will Deacon wrote:
> Assuming that a desirable property of an eBPF program is portability between
> CPU architectures, then you're effectively forcing the programmer to "assume

that is fundamental misunderstanding that being thrown in this thread.
bpf is not fixated on portability.
All projects that tried to come up with universal byte code miserably failed.
bpf program compiled for big endian won't load on little.
bpf program designed to be used on x86 will work horribly slow on nfp.
It will work, but will be innefficient. Hence we have alu32 mode in llvm.
More so maps don't map one to one to all archs either.
per-cpu map doesn't exist on nfp. we're still figuring out
an equivalent for it for nfp.
So, no, programs are not portable across architectures.
The programmer cannot assume that.
They could be portable in some cases and we're trying to keep portability
as much as possible, but it's not a "desirable property" that we're going
to sacrifice performance and usability for it.
If it helps look at bpf as a safe kernel module.
Does given kernel module work on all archs? No. Sometimes users only need
to recompile it and sometimes do heavy changes. smp_mb and load acquire
are the list things to worry about when folks trying to make
such 'safe kernel module' work on different archs.