Hello llvm-dev, I'm working on a project that is looking at using BPF as the underlying instruction set for running programs in a protected environment. We have a working prototype but have run into a few issues and missing functionality. It appears these might be due to BPF development being focused on usage in the Linux kernel. Our requirements are broader (rodata, shared objects with dynamic linking) and we hope to compile multiple languages down to BPF (C/C++, Rust, ...). Here is an example of the issues or missing functionality we've run into so far: - 512 byte stack size limitation - No support for returning structures from functions - No support in lld for BPF shared objects (though we have made local changes that adds this support that we'd be happy to upstream) - llc reporting unsupported relocations when C using rodata in a typical way Are there any efforts underway to broaden the scope of BPF beyond the Linux kernel requirements and what kind of other issues or known lack of support may we encounter? Thanks, Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181114/9600a7b6/attachment.html>
Josh Stone via llvm-dev
2018-Nov-14 19:42 UTC
[llvm-dev] Using BPF outside the Linux kernel
On 11/14/18 8:11 AM, Jack May via llvm-dev wrote:> I'm working on a project that is looking at using BPF as the underlying > instruction set for running programs in a protected environment. We > have a working prototype but have run into a few issues and missing > functionality. It appears these might be due to BPF development being > focused on usage in the Linux kernel. Our requirements are broader > (rodata, shared objects with dynamic linking) and we hope to compile > multiple languages down to BPF (C/C++, Rust, ...).Have you considered WASM for this project? It seems already closer to what you want, versus trying to force BPF in that direction.
Hi Josh, thanks for the response. Yes WASM is an alternative path we are considering. We have similar concerns as we do with BPF where most of the WASM focus is targeted toward browsers and more full-featured and complex VM environments Stepping off that path may lead to similar deficiencies or require pulling in more complex dependencies. Are there non-browser embedded leaning efforts going on in the llvm community? Thanks, Jack On Wed, Nov 14, 2018 at 11:42 AM Josh Stone <jistone at redhat.com> wrote:> On 11/14/18 8:11 AM, Jack May via llvm-dev wrote: > > I'm working on a project that is looking at using BPF as the underlying > > instruction set for running programs in a protected environment. We > > have a working prototype but have run into a few issues and missing > > functionality. It appears these might be due to BPF development being > > focused on usage in the Linux kernel. Our requirements are broader > > (rodata, shared objects with dynamic linking) and we hope to compile > > multiple languages down to BPF (C/C++, Rust, ...). > > Have you considered WASM for this project? It seems already closer to > what you want, versus trying to force BPF in that direction. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181114/b298e213/attachment.html>