|
|
Log in / Subscribe / Register

Halting problem

Halting problem

Posted Dec 4, 2018 12:25 UTC (Tue) by nix (subscriber, #2304)
In reply to: Halting problem by corbet
Parent article: Bounded loops in BPF programs

Yeah. The problem here is not the halting problem: the problem here is always finding an approximation that lets useful stuff past but isn't too complex to be worth it. The high time- or sometimes space-complexity of many algorithms needed by compilers is a routine cause of foul curses in developers of normal ahead-of-time compilers that don't run in kernel space: the approximations needed by something that runs in the kernel seem likely to be even harder.

(Really, it's a shame the verifier and JITters have to run in kernel space: this sort of work seems like the sort of thing far better done by an upcall to something in userspace, unprivileged but only installable by root -- only that would stop BPF from being used to protect the system *from* root, and it wouldn't help with the time problem at all since the kernel would still have to block the process installing the BPF to wait for verification/JITing anyway...)

It just makes me icky seeing that people are basically writing compilers that run in kernelspace. Surely there must be a better way.


to post comments

Halting problem

Posted Dec 4, 2018 14:05 UTC (Tue) by excors (subscriber, #95769) [Link]

Maybe the kernel should use KVM to launch a minimal Linux distro, and use that as the userspace to run the compiler/JIT/verifier in, so it's unprivileged and not constrained by kernel programming requirements. The distro and applications can be encoded as a blob in a signed kernel module as part of the secure boot chain, so the VM is as secure as the kernel itself and can be protected against the root user.

Halting problem

Posted Dec 4, 2018 16:18 UTC (Tue) by farnz (subscriber, #17727) [Link] (3 responses)

This actually sounds like a potential application for proof-carrying code. The user-space verifier could attach a simple-to-verify proof to the program it's about to attach (even if it's an arbitrary program with loops and other such weirdnesses) that the kernel can check.

Halting problem

Posted Dec 4, 2018 23:49 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

It really does. Heck the original Necula and Lee paper might as well have had 'BPF' written all over it in letters of fire ten miles high :)

Halting problem

Posted Dec 5, 2018 10:16 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

It would be rather surprising if a researcher at Berkeley working on Packet Filters was completely unaware of BPF :-)

Halting problem

Posted Dec 11, 2018 17:45 UTC (Tue) by nix (subscriber, #2304) [Link]

Oh yeah, that's true. I had forgotten their affiliation. :)

Halting problem

Posted Dec 8, 2018 7:02 UTC (Sat) by marcH (subscriber, #57642) [Link]

> The problem here is not the halting problem:

Did anyone say it was?

> the problem here is always finding an approximation...

The "feat" was just to never mention once the name of what this approximates.

The misunderstanding and overreaction is even more interesting.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds