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

  bpftool prog dump jited id 173

  bpftool prog dump xlated id 173 visual

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.

The NICs I could find that enable this behavior belong to Netronome:

https://www.netronome.com/products/agilio-cx/

I've been meaning to get my hand on one of these to play around with eBPF offload.

There is also XDP (a subsystem of eBPF) which lets you take action before the packets run up the entire network stack.

eBPF is not Linux only. Windows is investing into integrating it to their OS and some efforts have begun applying it to the BSDs. There's even a recent initiative to standardize the eBPF runtime.

eBPF can work with Dtrace's USDTs as well as dynamic u(ret)probes.

Dtrace on Linux is built on top of eBPF.

Does loading the eBPF programs and then letting devs attach them later work for your use case?

I wrote about the possibility of this with fd passing in a recent blog post: https://mdaverde.com/posts/cap-bpf/

I'm also working on agent that allows for this at https://bpfdeploy.io/

Running eBPF programs doesn't necessarily require compilation at runtime nor root privileges. Look into bpftool's skeleton generation as well as CAP_BPF.

With that being said, because eBPF programs can be compiled at runtime, it makes signing eBPF programs trickier. The kernel team doesn't want efforts such as bpftrace to be stifled.

It seems like the conversation on signing eBPF programs is still ongoing with an eye at looking at fsverity to help with the use cases here.

Root is still needed, so not an exploit. Still a simple straightforward example on how to use eBPF/libbpf to grab returned data from a userspace function call

Great clean example of using libbpf.

Latest of libbpf (which seems like you vendored) comes with ability to calculate symbol offset for you. Thoughts on using that instead of your custom logic?

I read this as, due to pamspy setting an eBPF probe, pamspy needs to know where libpam.so lives. Not that the pamspy needs libpam to be built

Why do you think cert collecting is fun?

I can see this being the case just for the fact that certs are usually paired a structured curriculum for learning a new skill. This takes a huge mental burden off and decreases time wasted in deadend exploration.

Both of MapQuest's mobile applications[0][1] have a high enough rating that I might consider trying them now.

[0] https://apps.apple.com/us/app/mapquest-gps-navigation-maps/i... [1] https://play.google.com/store/apps/details?id=com.mapquest.a...