mdaverde

The answer to miserable health isn't exercise. It's high quality sleep.

But others do

Agree with everything has trade offs but do not agree that they are equivalent in impact. Tradeoffs have tradeoffs

So much of HN now is medical & healthcare related

This was exactly my take. This language just got a whole lot of significant focus behind it

Literally, yes.

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.

Still, worth reading.

Just read your article: https://www.marginalia.nu/log/09-system-upgrade/

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

This is changing! (or technically, has changed!)

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.

[0] https://developers.facebook.com/blog/post/2022/03/31/bpf-ite...

Can you explain why you consider it to be worse?

eBPF is also working on signed programs [0]

[0] https://lwn.net/Articles/853489/

eBPF has changed several of these constraints [0]

- Verifier can explore up to 1million insns now instead of 4096

- 512 bytes of stack but with tail chaining you have up to 8k

- Bounded loops have been added. Unbounded loops are prevented by design to not stall the kernel

[0] https://docs.cilium.io/en/v1.12/bpf/

Bonus points because it's C99

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.

[0] https://github.com/libbpf/bpftool

Looks like eBPF support for HID devices will be available in the next kernel release (v6.2)

Source: https://twitter.com/kernellogger/status/1592786651968839683

Linux Plumbers Conf talk: https://www.youtube.com/watch?v=w708RnBEdvE

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:

  bpftool prog dump xlated id 173 visual

I learned about these commands through this blog post: https://qmonnet.github.io/whirl-offload/2021/09/23/bpftool-f...

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).

I wrote more about this here: https://mdaverde.com/posts/cap-bpf/

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.