101–110 of 192 posts
Off topic: this is the same Brendan Gregg of flame charts fame [0][1]. It has solved my skin quite a few times when trying to figure out performance bottlenecks in Python apps (using pyflame[2] to capture data and FlameGraph[1] to convert it to displayable SVG). [0] http://www.brendangregg.com/flamegraphs.html [1] https://github.com/brendangregg/FlameGraph [2] https://github.com/uber-archive/pyflame
Haven't used it till now (except maybe via nft?). What I'm not sure is: who is preventing BPF to be used as rootkits? Since they are run inside the kernel and cannot be inspected (?) can they be used to hide malicious activity?
I have a hard time understanding what you would use it for. I could understand a use-case, but I fail to understand why it would be that much useful. I have a sense it allows much better performance for horizontal scaling, but I'm not sure...
rather than specify a limited set of api entry points (like segment gates) that you try to make safe....you can provide general security and resource guarantees and let the consumer do what they need. so that's cute, but imagine the round trip reduction (nfsv4 does this to a very limited extent) and increased generality.
what if your btree traversal could be safely run on the storage server.
Earlier quoted context omitted.
You can maintain production safety by using a BPF->kernel module compiler. This additionally removes the need to have the bpf compiler in the kernel, reducing both core size and vulnerability surface area. No reason BPF must imply JIT
The end goal with bpf is to allow arbitrary untrusted programs to load bpf programs. If you were just loading kernel modules you wouldn't be able to maintain kernel integrity and let arbitrary programs load code.
if i like the guarantees that BPF gives the kernel, and want to embed it into my user-space software so that it can execute BPF programs received from other untrusted processes, are there any hints on where to start? the "BPF beginners" material i come across doesn't seem to discuss this use case.
Two such implementations exist. uBPF has a simple implementation. This implementation is likely not feature complete, as it is not regularly updated and the kernel BPF validator keeps getting new features. DPDK also has an implementation of BPF. This appears to be actively developed, but it also comes with a lot of baggage from DPDK. It may be possible to fork for this purpose, but it appears to primarily used for running traditional network filters on incoming packets in userspace.
What you are looking for is a really interesting possibility but would require a significant software engineering effort.
If you relax the constraint that BPF runs in userspace, it is possible to insert userspace dynamic tracing points (USDT) into your code, which will call out to a BPF program in the kernel when executed.
Earlier quoted context omitted.
Real-time, low latency, network-based applications. At the pace of network events, CPU is still very fast by perhaps at least order of magnitude. However, latency introduced by system calls is significant. This allows you to run certain classes of application in kernel space with these overheads largely mitigated. Principally it's monitoring and "observability" applications, but apparently it's much more flexible now…
Could you allocate a memory dynamically inside your BPF program?
* you can use maps which are persistent key-value stores provided by the eBPF runtime, and you can call out to approved C functions provided by the kernel, but those won't allocate memory for you.
Earlier quoted context omitted.
> "if this exceeds some limits or bogs down system for more than X milliseconds, disable and give error". AFAIK indefinite loops in a BPF are not allowed: The kernel eBPF verifier will reject to load such programs. So the execution time of BPF programs will not be variable time and will be predictive. I'm not sure if users need to care about the cases of long execution times when no loops are allowed.
How is that possible?? If true, that would imply BPF programs are not Turing complete.
The programming language Zig is aiming to be able to calculate the stack requirements for a given function. This has enormous benefits if you can do it in areas like embedded software. You can guarantee that you don't run out of memory (functions in Zig can't use an allocator without permission either). But to do this, functions can't do recursion, and probably can't be Turing complete in general. I don't think Zig will ban recursion, but it will give you some powerful tools/options if you avoid it where you can.
eBPF can be viewed as a mechanism to safely run user code in kernel since it uses a DSL and a compiler before the byte code is executed in kernel. This opens up doors for running performance critical functionality in kernel without having to bundle it with the kernel or very tightly coupled with the kernel version. Optimizing FUSE is an example: https://extfuse.github.io/ I expect custom security auditing software, r…
> Server abilities can be changed by uploading JS functions/libs..
> Want to search a file formats meta-data on the server? Upload JS to read the meta-data and index it, and provide the search options..
> Servers should also use the best options for the tasks they provide: Grep to seach text -- and not Grep like functionality, but the optimized binary for the platform the server is running.
> Locking, linking, ACLs, and binary access should all be changable by JS.
Earlier quoted context omitted.
Bytecode + compiler was also how both Flash and Java Applets worked. Have we forgotten how secure those were?
It's also how wasm works, and in some sense -- JavaScript. Somehow, these introduce much less security problems.