As example, the north bridge isn't as explicit today as the document makes it seem. A lot of functionality that used to be reserved for the north bridge is now being tucked away into the CPUs or motherboards themselves.
You got rid of a lot but where did the functionality for those tools go? I understand wanting to get rid of containers & Kubernetes, but did you rewrite/bake the functionality in to your app? or maybe not care about monitoring and logs temporarily for now?
Question: how do you reliably deploy? And if it's just scp-ing tarballs, how do you handle dependencies? Do you run & upgrade any third-party processes that rely on having their filesystem or deps?
Struggling with this because even in a small app in a Linode box, I don't mind just cp-ing my bins but there's always other things/versions they need. Thinking of bringing in Ansible to help me out here.
Deploying feels easier in the container, Kubernetes world
eBPF recently added the ability to look through internal data structures through iterators [0] so instead of parsing text we can run a program that traverses through all the task_structs and pushes the exact information we want to userspace in the form the developer wants.
So, alongside other tradeoffs, it's more flexible than syscalls.
In the same way out-of-tree kernel modules are enforced to license themselves as GPL if they intend to use a lot (if not most) of the available functionality, eBPF programs fall under the same restrictions.
bpftool[0] allows you to see which programs are currently running in your system, their bpf asm instructions and whether they are GPL-compliant through `bpftool prog show`.
Of course, we still need companies to actually release the source code of their eBPF programs somewhere for the promise to be fulfilled.
It would be nice to see a comparison of FreeBSD's capsicum vs OpenBSD's pledge vs Linux's landlock features. It seems to me that the general vision of these projects have overlap but the implementations wildly differ.
Another question I have is that we haven't seen popular adoption of "capability-aware" Linux programs prior to the above efforts. While obviously it would be beneficial for users for developers to adopt these patterns, I'm skeptical these will start to take hold now? Possibly the adoption method will be runtimes that do this under the hood before fork/execve the application?
In the near term with a recent-enough BTF-enabled kernel, bpftool should be enough for an "ambitious" user to understand what objects are being run on a system.
Unfortunately, "ambitious" here meaning enough to actually understand more than just what eBPF is but also the significance of each hook, what effect the bpf program has (most eBPF programs are GPL-licensed), and which processes have access to these objects.
This is not easy, especially considering that the shape of eBPF changes with each kernel release.
You can see the interpreter instructions through bpftool:
bpftool prog dump xlated id 173
To see the JITed instructions:
bpftool prog dump jited id 173
For the interpreted insns, you can also see the instructions in different forms, which is pretty neat. For example you can get a control flow graph in DOT format with `visual` specified at the end:
In 2020, CAP_BPF was added to allow the use of eBPF.
For most programs, you'll use a combination of CAP_BPF, CAP_PERFMON and/or CAP_NET_ADMIN. For some edge cases (such as hardware offload), you'll need the entire CAP_SYS_ADMIN (basically root).
While I do agree generally that we're still experimenting with the guardrails around eBPF, it seems like the more fundamental problem of the "ease of privilege escalation" is what we should be focused on?
But I can see how eBPF itself might be considered too powerful to wait for that to be solved.
I'm honestly more worried about Linux desktop/small startups that can't afford expensive commercial guidance and are likely to not understand/care about the implications of eBPF until its too late.