Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
ebpf
ebpf-go is a pure-Go library to read, modify and load eBPF programs and attach them to various hooks in the Linux kernel.
> I'm referring to the fact the eBPF will be available across Microsoft, Apple, and Linux, and there is no other technology that will be able to offer that.
I don’t know if there’s some qualification im missing in your statement, but does this not count?
- https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
- https://opensource.apple.com/source/dtrace/
- https://docs.freebsd.org/en/books/handbook/dtrace/
- https://github.com/dtrace4linux/linux
One of the big wins is not so much “build and run your own stuff” but there are very nice low-cost (in terms of compute) performance utilities built on eBPF
https://github.com/iovisor/bcc
There are so many utilities in that list; there’s a diagram midway down the readme which tries to help show their uses. bcc-tools should be available in any distro.
Also, Brendan Gregg does a ton of performance stuff that is worth knowing about if you check out his other work. Not eBPF only. Flame graphs are useful.
It may become a footnote on Linux, but Linux isn't the only system out there -- and DTrace remains alive and well in many systems (not least in its reference implementation in illumos[0]).
[0] https://github.com/illumos/illumos-gate
> While this is true from a certain perspective, machine code creates a system which must grand access to many things to become usable. A shared file system is a good example of this. Some software could easily echo a line into you .profile that tries to launch a key-logger, and this works in many cases.
That's common, but it's certainly not a requirement to run native code. For example, we've done a pretty good job at retroactively fixing that while preserving backwards compatibility with containers (I can, and have run normal official Firefox binaries inside a docker container with zero access to my real home directory) or sandboxes like flatpak (bubblewrap). If you want to run real native binaries but don't have to preserve backwards compatibility, then it gets easy; genode ( https://genode.org/ ) does a lovely job of truly practicing only giving programs what access you want to give them.
> The expectation of software existing as opaque files creates a huge amount of work for the OS in verifying the exact behaviour of the software as it runs (and in ways which can often be circumvented), rather than a source-based approach in which malware is never allowed to touch the processor.
I think you're overoptimistic regarding what you can do with the source code short of manual (human) auditing. I mean, sure there are things you can scan for to try and catch bad behavior, but in the case of actual malice I wouldn't trust automatic code analysis to protect me.
>> I'm typing this on a nice comfy GNU/Linux box where the only blobs are some firmware
> So you suffer the worst of both worlds then. You've had to download and compile the source yourself, but as the software is designed around being distributed as blobs, so you enjoy none of the benefits that might come from source distribution.
I have no idea why you think either of those things? Depending on the distro I certainly can compile from source on my own box (ex. Gentoo, NixOS), but I can also use precompiled binaries (ex. Debian, NixOS) while still having it be trivial to go find the exact source that went in to the binary package I downloaded (this has gotten even stronger with Reproducibility efforts meaning that I can even verify the exact source and build config that created a specific binary). The actual application software and OS are available as Open Source code that can be audited, with binaries available as a convenience, and the only remaining blobs (unwelcome but impractical to fix so far) are firmware blobs with relatively constrained roles (and on machines with an IOMMU we can even enforce what access they have, which is a nice mitigation).
This [1] makes me think gobpf uses C bindings to bcc, so golang does not compile to eBPF, bcc does.
[1] - https://github.com/iovisor/gobpf/tree/master/bcc
Oh, no I don't mean that arbitrary Go compiles to eBPF. Apologies if I gave that impression. I meant that there are libraries that let you compose eBPF programs in other languages. But you're still putting together an eBPF program, just like you can assemble JSON with Go but you can't compile an arbitrary Go program to JSON.
Cilium's eBPF library is the Go one I had in mind: https://github.com/cilium/ebpf
Here's an example from that repo: https://github.com/cilium/ebpf/tree/main/examples/ringbuffer