LWN: Comments on "Securing BPF programs before and after verification"

Just run the JIT twice

mbland — Tue, 17 Dec 2024 17:39:14 +0000

This is an awesome comment, and that did end up being sort of the solution for the Android case!

Since the only runtime-loaded BPF programs on Android presently are SECCOMP policy filters, and these are cBPF and not eBPF, and it is (pretty) straightforward to do what you suggest and run a machine-code level purity test on cBPF programs after after (or simultaneous to) marking them executable at EL2 or EL1!

Sort of "working" code for this is here:
https://github.com/KSPP/linux/issues/154

Note that this implementation is buggy and not totally generic. It only supports one-page programs, iirc. I was quick to learn chrome has multi-page cBPF load-ins when working on a deployed implementation.

I was able to get a stable implementation working with a couple of changes to the above on Motorola phones, and am trying my best to release a fuller, open-source, permissively licensed, and modular (as in kernel module) for hardening against Qualys 2021-style (and other) attacks in the next few months.

Not an excuse, but explanation for the delay, since I want to put my code where my mouth is: I am *still* dealing with Snapdragon processors page table (and memory caching) management months later. -_- ! The hoops the Gen 8 series needs you to jump through just to perform an SMC call are bogus IMO. E.g. https://android.googlesource.com/kernel/msm/+/refs/tags/a... : you're telling me if I want to transition to EL2 to register a protection, I have to have a retry count? What if it never succeeds, and that is a critical security operation? What the heck! (-:

The tl;dr is a good executable code verifier sort of needs to also hook into/watch each task's allocated PGD and sub-tables during fork.c's duplication of the mm_struct, which is totally doable, but hardware specific nonsense makes it an engineering struggle, so it is taking me a while to get the code out there (my testing devices are all snapdragon chipsets).

Chandrasekhar limit on the mass of the kernel

jezuch — Sat, 22 Jun 2024 09:34:20 +0000

I guess right now the more relevant limit on the kernel is the Eddington limit 😜

Chandrasekhar limit on the mass of the kernel

alkbyby — Thu, 13 Jun 2024 02:50:55 +0000

Well said and +1. This has came up few times in the last several month on LWN. Each time (or nearly each time) there are people asking in comments why something has to be in-kernel. It would be mega if someone comes up with clear explanations.

What's the reason to embed BPF programs with the kernel itself?

ringerc — Wed, 12 Jun 2024 20:18:27 +0000

Right. Most of all of the endpoint "security" vendors like CrowdStrike, Vanta, SolarWinds, IBM etc seem to have very opaque and secret kernel modules that do god-knows-what to the system, for example.

What's the reason to embed BPF programs with the kernel itself?

iabervon — Wed, 12 Jun 2024 18:23:02 +0000

If scheduler development switches to normally compiling to BPF for schedulers people are using, it might then make sense for the default scheduler to be in BPF, but loaded before there are user space tasks. More generally, it would make sense for the policy you get until you load your custom policy to be qualitatively similar to the custom policies you could load, which suggests that the mainline kernel ought to compile some code to preloaded BPF instead of native code.

What's the reason to embed BPF programs with the kernel itself?

daroc — Wed, 12 Jun 2024 12:58:11 +0000

> I wonder. Is this done as a way to sidestep the GPL license and not release them, where modules need to be released instead?

The BPF loader actually only loads programs that (claim to be) GPLv2 licensed. So in this case, embedded BPF is not likely to be a workaround for licensing. I believe the use case is for distribution kernels that want to include BPF programs, simplifying the kernel initialization process/distribution process.

Chandrasekhar limit on the mass of the kernel

farnz — Wed, 12 Jun 2024 11:36:55 +0000

I like the compromise the DRM subsystem takes for GPUs; the kernel verifies that the stuff from userspace can only access resources the sender already has access to via other means, and not other parts of the system, but otherwise does not interpret the information being sent into the kernel.

If userspace wants to ask the GPU to trash the current process's memory, that's fine (and it should also be fine for a BPF program to trash memory belonging to processes you can ptrace, for example). But you can't use the kernel interface to bypass the kernel's security mechanisms; if you ask the kernel to alter PID 1's memory, and an LSM or traditional permissions would say "no", then the BPF program (or whatever) should be rejected.

This sort of "verify that you're not breaching security barriers, then trust" seems to be a reasonable compromise; it doesn't matter if the userspace turns out untrustworthy, since it can only do damage that it could already do by some other means.

What's the reason to embed BPF programs with the kernel itself?

Wol — Wed, 12 Jun 2024 10:01:17 +0000

> I don't think backdoored dependencies become less malicious if they are statically linked.

But static dependencies are frozen at build time by the developer

> In both cases, unless you audit all the dependencies, you don't know what might be running.

And with dynamic loading, how CAN you audit all the dependencies? That's the point you're missing - an attacker can corrupt a dynamic dependency at run time, a static dependency can be audited by the developer.

> I wonder. Is this done as a way to sidestep the GPL license and not release them, where modules need to be released instead?

That horse has bolted. Not all modules are released as GPL or even Open Source! There's plenty of ways round it, this could just be one more. I think it's a safe bet manufacturers will find it hard to get closed-source bpf modules into distros, but it'll be user pressure not legal force.

Cheers,
Wol

What's the reason to embed BPF programs with the kernel itself?

LtWorf — Wed, 12 Jun 2024 09:04:22 +0000

> Singh recommended that trusted BPF loaders be statically linked.

I don't think backdoored dependencies become less malicious if they are statically linked.

In both cases, unless you audit all the dependencies, you don't know what might be running.

> where BPF files are embedded directly into the kernel during the build.

I wonder. Is this done as a way to sidestep the GPL license and not release them, where modules need to be released instead?

It might also be because BPF interface is more stable than modules, so they are more durable across versions?

I have no experience with linux kernel development, so I'm just wondering.

Just run the JIT twice

cesarb — Wed, 12 Jun 2024 02:24:00 +0000

> But if an exploit can write to a page before it is made executable, that is nearly as good. For BPF, this means that exploits might try to exploit other write-gadgets (parts of existing code that can be misused to write to memory) in the kernel to overwrite a page while the just-in-time (JIT) compiler is also writing to it. [...] There are potential mitigations, however. [...]

Let me propose a (not entirely serious) solution to that (I don't know whether it was one of the mentioned potential mitigations): just run the JIT twice. Once before protecting, writing to the page, and once more after protecting, reading from the page and comparing instead of writing. If the comparison fails, panic the kernel. (Of course, that would depend on the JIT being deterministic.) And if you want to protect against someone somehow running code on the page before it has been checked, make the page executable only after the comparison ends.

Chandrasekhar limit on the mass of the kernel

intelfx — Tue, 11 Jun 2024 20:40:45 +0000

> Eventually, he settled on a different approach: moving the loading of BPF programs into the kernel. If relocations could be performed in the kernel, then the bytes read from disk could be signed using fs-verity, which would let the kernel ensure they had not been tampered with as long as the file system itself is trusted. Kapron suggested an approach where a user-space program could present a file descriptor to a file on an fs-verity filesystem and the kernel would handle the rest.

Honestly, this feels like a step backward from what I'd call a good OS design.

Every once in a while a question of trusting specific parts of userspace comes up — and the answer to that question is invariably "let's stick it into the kernel" (with the assumption that everything in the kernel is trusted). I'm afraid this is not a sustainable approach.