Is the code working?

[PallHaraldsson]

I noticed the package waiting for registration, and was very intrigued. I didn't want to block it with [noblock]. Maybe code not yet working is ok to register, or I didn't use it correctly?

[jpsamaroo]

Yes, you just need a working libbpf installed (JLLs to come), and to run it under sudo to be able to run the bpfprogattach* functions. When I get the chance I'll setup some tests that show how real kernels would be written and enabled.

[jpsamaroo]

Please check out BPFnative now! If you have libbpf available locally, you can run the tests to confirm things are working. If you want to test kernel probing, you can run the tests as root (just set the environment variable BPFNATIVE_ROOT_TESTS=1). It will load simple probes into the kernel to test that things actually work (but they don't do anything destructive, nor will they ever try to without serious warnings). Still, if you're not me, run the root tests in a VM or in Docker.

[PallHaraldsson]

I ran the tests (including as root), but looking over them it seems I only generated (BPF) ELF code but didn't run it in the kernel, and seemingly I only need to get it to a file (not string) and use some tool to run it.

I however do see "BPF CO-RE (Compile Once – Run Everywhere)", kernel portability non-trivial, and I assume you do not support that? Or do those tools work with your (generated) code? I don't really have any need for this, I just kind of like to compile one trivial Julia program, even noop and/or println("Hello world!") to say I ran Julia in the kernel...

I wasn't expecting it possible (until this package), nor for Python, while I do see:

https://medium.com/@yon.goldschmidt/running-python-in-the-linux-kernel-7cbcbd44503c

I don't expect full Julia with REPL on the horizon in the kernel... while Python with REPL can.

[jpsamaroo]

it seems I only generated (BPF) ELF code but didn't run it in the kernel, and seemingly I only need to get it to a file (not string) and use some tool to run it.

It can generate BPF assembly or object code based on the format flag passed to bpffunction; set it to format=:asm if you want assembly, since object code is the default. The object output, however, can be directly written to disk, as it's just a standard ELF object file.

Also, we are running in the kernel with BPFnative - that's the point of the root-only tests, to load code into the kernel. I've personally tested that I can hook into kprobes and modify BPF map values from there (which is also how the root-only "map interfacing" test work).

I however do see "BPF CO-RE (Compile Once – Run Everywhere)", kernel portability non-trivial, and I assume you do not support that?

I do want to have CO-RE support, but right now our BTF output is untested and probably invalid. I have an issue open for that. The recently-added vmlinux support should at least help us to get access to our current kernel definitions. If you want to help out with that, I would greatly appreciate it!

I don't really have any need for this, I just kind of like to compile one trivial Julia program, even noop and/or println("Hello world!") to say I ran Julia in the kernel...

You shouldn't need CO-RE for this, but string and logging support are something I'm actively working on (it's not trivial due to how Julia handles strings).

I wasn't expecting it possible (until this package), nor for Python, while I do see:

https://medium.com/@yon.goldschmidt/running-python-in-the-linux-kernel-7cbcbd44503c

I don't expect full Julia with REPL on the horizon in the kernel... while Python with REPL can.

This would definitely be feasible to (partially) implement, although it would be a lot of work. We can already detect kernel structure layout, but I'm not sure how to allocate/free kernel objects dynamically. Implementing a GC would be non-trivial (and no, we can't reuse Julia's built-in GC, since it expects to be able to traverse pointers on its own), and much of the multithreading stuff seems very non-trivial to implement. You also probably don't want to try to do parsing or codegen within the kernel; best to leave that to a userspace Julia process.

If you want to try your hand at this, feel free, I'd be happy to provide advice and fix any bugs you find along the way!

[jpsamaroo]

Check my comment in #20 for how to generate output from BPF kernels!