An example of eBPF use in production is NGINX webserver, when running as multiple processes and using just one shared UDP port for QUIC & HTTP/3, the eBPF program would route the packets to the correct NGINX webserver process. Which is a very useful optimization.
@@allanguwatudde7623 yes, a sort of loadbalancing system, the kernel already had a function for this for TCP-connections which is SO_REUSEPORT, but not for UDP and definitely not any support for QUIC. So this was a fairly simple way to do this for QUIC.
Great Episode! I am writing my bachelors thesis on a protocol that uses eBPF to send duplicated udp packets over an redundant path. It also deduplicates the packets with XDP at the destination, it's been really interesting. Also, BCC indeed is a bit dated as far as I read - thats why I used libbpf-rs, which I am really happy with so far. One huge plus of libbpf is that you can write portable code (they call it Compile Once - Run Everywhere) - basically it abstracts away the memory accesses. This way the changing kernel source won't affect compiled eBPF Programs.
@@sachamm Yes exactly, it's supposed to be used for control messages that require very low latency. While TCP is reliable it would also introduce head of line blocking
@@richardclegg8027 That's probably true, but so far the protocol is really lightweight and with eBPF the connection establishment can be done from Userland so it doesn't slow down the data path. I will need to look further into multipath quic when we get to the evaluation. Thanks for your comment!
Similar to shader programming where the c code is passed as a string to the GPU driver. The GPU driver compiles, schedules, then executes the shader on whatever hardware you have.
@@jordixboy The code of the shader is not compiled, it's embedded in your (compiled) program as raw string and passed to the driver. That also means it really easy to extract the shader code from your program. In newer frameworks, it can be compiled to some intermediate binary representation which is halfway between source code and the final binary.
You said the compiler rejected the infinite loop, but the kernel actually contains a verifier to prevent infinite eBPF programs from loading, and from the traceback it looks like the failure happened when you tried to attach the program, not when you compiled it. Also, the failure location is given in instructions, not line numbers, so this would be a very unusual compiler error. The fact that eBOF programs are verified by the kernel before being run is an important part of the system, because it means the kernel, not a compiler, determines what kind of programs are safe to run (and the kernel can adjust that definition over time).
Dr Clegg looks surprisingly similar to Tarantino! Interestingly I am now finishing up my thesis and at one point I was using eBPF to solve a problem. It is such a powerful tool.
When I first looked up “eBPF”, the “packet filtering” bit threw me off 😅. Explaining how this went from a simple packet filter to what eBPF is now was very helpful.
That example looks very cool - I usually implement LuaJIT in my projects if i need any extensibility, but i have considered alternatives incl. BPF. It's probably too low level for my needs, but I may play around the example as I've never used BPF before.
I have used eBPF for my master thesis (CS) and while eBPF is extremely interesting for including project extensibility it has very serious limitations. The most important for general extensibility is that it has no floating point support. That said for program extensibility there are ready to go userspace eBPF VMs that you can easily include the most prominent is known as uBPF (I can't share links those comments get shadow banned on youtube).
Fascinating stuff! Would be nice with another video going deeper on eBPF, looking into how we determine if a program is safe to run. And yes ... everybody loves the Fibonacci sequence hehe
Importantly, the kernel verifier not only prevents guaranteed infinite loops, it also prevents any loops which can't be proven to be finite. That might seem like a trivial difference, but it means that the subset of "runnable" eBPF (as opposed to all compilable eBPF) is also not Turing complete, because you can't prove whether or not an arbitrary Turing machine holds, so if we only allow turing machines for which this is possible (i.e. equivalent automata of a higher Chomsky Type), we've excluded some possible programs. I would have really liked a more in-depth look into eBPF bytecode in the video for that reason. As far as I know the verifier checks the programs control flow graph, and if that is not acyclic, rejects the program (consequently loops have to be unrolled by the compiler to be able to pass the verification). But I would have liked to know a bit more about the verification process, and what additionally goes into it. I'm still glad you've shown this demo, thank you!
What stops me from writing acyclic code that will take longer than the lifetime of the universe to terminate? The entire idea sounds naive to me. Unless they are setting a low (1 minute) limit on top, without the ability to restart... and even then one can probably still do some rather malicious things with it.
This is kind of missing the part of the video where he actually runs the infinite loop and sees what happens to the computer when a rogue kernel process actually runs... Still very interesting video, as someone who worked with userspace networking code (kind of going in the other direction with RDMA - moving all the TCP processing off to the NIC and utilizing userspace to do the rest), this BPF stuff is pretty neat!
You can not run an infinite loop with eBPF on Linux, all eBPF kernels need to be statically verifiable, you can not even use arguments for loop termination conditions. If the program is deemed not safe for execution the Linux kernel will refuse to run it.
@@h..hThere will be some configurable limit, typically not defined in loop iterations but in a amortized 'computational complexity' cost estimate based on the amount data moved, the calls made and the loop iterations as well as the number of branches
@@h..hSo it used to be you couldn’t even have bounded loops, but kernel version 5.3 allowed that. The big limit now is a maximum of 1 million instructions. The reason bounded loops are allowed is because the eBPF verifier will be able to expand the loop to determine the number of instructions it will take. Of course, if you’re writing a program to run on kernel versions lower than 5.3, you can’t even have bounded loops, which I can say from experience is incredibly limiting
Super interesting, I've never heard of this before. I see in the comments that there is even an intermediate compilation standard. Presumably that's something like JVM bytecode but for a kernel VM. I do have to wonder about security though. All the problems with virtual machines, now in your kernel!
Justine Tunney used eBPF to make really easy-to-use process-level sandboxing on Linux, inspired by OpenBSD's pledge/unveil syscalls. I would paste a link but Google would eat my comment.
I'm getting bad flashbacks seeing BPF, XDP and other stuff like this, did some work with that and it was a real pain, although mostly because of the custom kernel and NIC drivers.
It used to be particularly difficult to get working right but there has been a lot of consolidation of the number of available runtime frameworks, the runtimes are typically incompatible with one another making the experience pretty hard to understand and use. Especially now that LLVM can compile bytecode and that we have BTF, a system to help make the bytecode work regardless of Linux kernel version, things have settled quite a bit.
A common topic during blackhat and defcon for the last years indeed, although making them undetectable and persistent is actually particularly hard. Especially since the events registered can be easily queried and the events are cleared every time the system reboots.
This is so weird, I just learned about eBPF like a week ago and got really interested in it and started writing some toy programs with it to get a feel for it. So seeing a Computerphile video uploaded just now is kinda creepy.
I build my own kernels, and I never include anything BPF in them. Same goes for IPv6, Bluetooth, WiFi, initrd and so on. All of a sudden the kernel is a mere 5 MB - instead 100MB plus kernel objects plus initrd.
@@tablettablete186 sudo is a naive workaround for the failed "root" concept. The average user should NEVER have to use it. Look, all of this was invented at a time when computer security was not a problem. Today it is. Nobody was doing their bank transactions on a multi-user mainframe in the 1960s and early 1970s. Except for the bank, that is... and they could physically secure their hardware and the only possible "hackers" were their own employees who had hardware access. That made these simple minded concepts somewhat workable. They are not workable today.
The Linux eBPF verifier will determine that your program is not statically verifiable and not run it. All eBPF programs need to be statically verifiable by the Linux kernel prior to execution. The static verification also checks for things like guaranteed termination of the program, so you can't use arguments in loop counters for instance.
@DantalionNl the verification isn't to stop malicious code, it's to stop you from bricking your OS by accidentally looping forever in kernel space. You need yo be root or have the CAP_BPF capability to inject eBPF code. It's assumed you will only be granted that permission if you're a trusted user.
So if a program require a kernel feature but my kernel isn't compiled with that feature I could use eBPF to essentially run the program without the need of recompiling the kernel with necessary feature?
Mostly no, eBPF programs (in Linux) can only run as events based on what the kernel is doing so whenever a packet arrives on a specific interface. However, you could never run it as a driver for the network interface in the first place. So similarly you can register events on filesystem operations but can't implement the filesystem itself.
Sort of depends what you mean by feature. If your kernel is not monitoring something at all you can't make it do so using eBPF. But if you want a higher level feature that you can derive from other features then you could in theory.
The correct ways to monitor use of a kernel function on Linux is ftrace. Ideally systemtap would work but in my experience it doesn’t. Dtrace on the other has always worked as documented (on those platforms). For general code write a module.
Module is kind of a half way house but it is a lot if all you want to do is (say) write a little monitoring program. Plus now your user needs a module installed for your monitor and then they need another module for the next person's monitor and so on and so on... pretty soon they got ten extra modules in their kernel.
Not a computer scientist, but as far as I can tell this is less about monitoring the use of the kernel and more about using the kernel to monitor something external to the kernel, eg a hardware interface of some sort. This kind of makes sense given that it's built out from a network interface monitor, and certainly to say that it's "incorrect" when it's broadly used in practice would seem to render the term "incorrect" somewhat meaningless.
Why would a fibonacci number with N larger than 40 overflow? He was using 64 bit unsgined integers so the limit would be over 18446744073709551615, which is between N=92 and N=93
The immediate 2 questions I have are: Did they solve the halting problem? And have you tried expressing recursion in terms of the Y combinator? You really need to be careful with your language design when you want to guarantee all programs in it will terminate.
It is kind of the opposite of the halting problem. Knowing what class of programs halt is hard. But specifying a subset of programs that definitely halt is easy.
!?! The immediate 2 questions I have are: - What does solving the halting problem have to do with eBPF ? - Why recursion, and expressing it with the Y combinator is so important for monitoring an OS? It's just an embedded language for a very niche application, not haskell.
I am sure you can use any language with a C FFI the way Python is used here. The actual eBPF code is in C, but Rust (and apparently others) can be used. Go needs a runtime, so it can't be the actual eBPF program. (It would be too big for the verifier to accept)
Solving the halting problem would be having a compiler that states whether a program halts or not. What this compiler says is either 'yes, this program halts', or 'I can't say anything about whether it halts or not'. If the compiler can't say anything then the program is treated as if it was non-halting and is not allowed to run in the kernel.
Given the limitations of eBPF programs, there is little risks of that happening. The only commonality eBPF bears with JavaScript is they both run on VMs, this is it. eBPF is more like the kernel WASM rather.
@@richardclegg8027 What an awful analogy - I wish they didn't. I'm glad I managed to learn about this before I heard the analogy - well, perhaps the video mentioned it, but it showed what it _really_ was like, and it was nothing like that analogy. I hope someone at these conferences would hold a speech about why this analogy might be better left out. When I hear _"like Javascript, but for kernel",_ it immediately raises a crapton of red flags in my mind. But when I saw this video I actually thought of it as quite cool technology with potential when used the right way.
This thing is designed for monitoring purposes, this is not kernel module replacement. Also, afaik microkernel modules don't run in userspace. They just isolated from kernel so you can't crash a kernel with null pointer dereference.
I think there's a guy whom the devs can ask about whether their "infinite loop detection" system can ever work. Name was Kurt Gödel, if I remember correctly.
Question: is there any reason to do this in python, or is it because the original code that used python for logic and sorting/filtering of data? Without knowing how much stuff the python class does on the background, it seems like a method to circumvent any help your IDE could offer for writing C, which sounds like a bad time. But if the python-class is doing some magic on the background, writing this in C directly could be much more code than shown here.
Python is pretty easy for people on the channel to read. You could write in a lot of languages. The python part of the code does not need to be highly optimized.
Wow, so this is a fully fledged Linux backdoor, then? How can this be safe at all? Surely there must be exploits that can bypass whatever heuristic they have that prevents compiling and running malicious code.
@@alpo789 I never understood why people think that "root" is safe. For 99% of users it's more likely that the hacker knows how to become root before the user does.
They don't need to solve the halting problem. They need to specify a subset of programs that definitely halt. It is kind of the opposite of the halting problem. They rule out some program which would be fine to run and would halt in time.
@@richardclegg8027 Right, that makes sense. Although even that couldn't prevent an algorithm that eventually halts but does so after an inordinate amount of time. Unless... maybe if you constrain what kinds of loops are allowed somehow? Or just not allow loops at all?
@@pv2b I'm not honestly sure at that point. If you want to look it up you can look up the eBPF verifier. I thought about the same myself before making this but the video was getting long already.
Too slow, man - I'm up to 3:40 and you still haven't gotten to the POINT of what eBPF actually is. You just made me curious, so I've gone now to look it up elsewhere...
@NumberOneRated1997 TH-cam isn't the place for creepy roleplaying. Maybe find some friends online to do that with so you aren't spamming up someone's channel, yeah?
![TokenFormer [Paper Review]](http://i.ytimg.com/vi/YOEwihvT_kc/mqdefault.jpg)
![TokenFormer [Paper Review]](/img/tr.png)
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
The king of gesticulation is back and I am here for it. What an interesting topic.
Making me nervous
"King of gesticulation" - I may put that on my CV.
had to minimize the screen, highly annoying looking an engineer talking like a street fraudster
Gesticulation tend to show enthusiasm. Enjoyed the episode 😊
Oh, man… have you ever seen Italians’ gesticulation while speaking?)
An example of eBPF use in production is NGINX webserver, when running as multiple processes and using just one shared UDP port for QUIC & HTTP/3, the eBPF program would route the packets to the correct NGINX webserver process. Which is a very useful optimization.
So load balancing?
@@allanguwatudde7623 yes, a sort of loadbalancing system, the kernel already had a function for this for TCP-connections which is SO_REUSEPORT, but not for UDP and definitely not any support for QUIC. So this was a fairly simple way to do this for QUIC.
whoa
there's an HTTP/3 now?
Great Episode!
I am writing my bachelors thesis on a protocol that uses eBPF to send duplicated udp packets over an redundant path. It also deduplicates the packets with XDP at the destination, it's been really interesting.
Also, BCC indeed is a bit dated as far as I read - thats why I used libbpf-rs, which I am really happy with so far.
One huge plus of libbpf is that you can write portable code (they call it Compile Once - Run Everywhere) - basically it abstracts away the memory accesses.
This way the changing kernel source won't affect compiled eBPF Programs.
Interesting thesis, is the idea to increase reliability of UDP?
@@sachamm Yes exactly, it's supposed to be used for control messages that require very low latency. While TCP is reliable it would also introduce head of line blocking
How do you like Rust?
@@Snsee Presumably your competitor is multipath QUIC type proposals. Very cool ideas anyway. And yes, if I made this again I would use libbpf.
@@richardclegg8027 That's probably true, but so far the protocol is really lightweight and with eBPF the connection establishment can be done from Userland so it doesn't slow down the data path.
I will need to look further into multipath quic when we get to the evaluation. Thanks for your comment!
Similar to shader programming where the c code is passed as a string to the GPU driver. The GPU driver compiles, schedules, then executes the shader on whatever hardware you have.
A little yes. You're targetting your code somewhere else where (for whatever reason) it will be more efficient).
how can that be done if the code is compiled? its still code obviously (in binary) but as a string?
@@jordixboy in this case it is compiled to something like byte code for a VM as Java does it.
@@jordixboy The code of the shader is not compiled, it's embedded in your (compiled) program as raw string and passed to the driver. That also means it really easy to extract the shader code from your program. In newer frameworks, it can be compiled to some intermediate binary representation which is halfway between source code and the final binary.
nteresting, could you guys send me some article to read more about it?
You said the compiler rejected the infinite loop, but the kernel actually contains a verifier to prevent infinite eBPF programs from loading, and from the traceback it looks like the failure happened when you tried to attach the program, not when you compiled it. Also, the failure location is given in instructions, not line numbers, so this would be a very unusual compiler error. The fact that eBOF programs are verified by the kernel before being run is an important part of the system, because it means the kernel, not a compiler, determines what kind of programs are safe to run (and the kernel can adjust that definition over time).
eBPF is fantastic! we used it all the time in grad school. it's an absolutely essential tool for doing OS research
I always pictured userland above the kernel and the hardware at the bottom.
I will have to watch this video upside down to be able to follow along.
Are you in Australia? Hah... as long as the kernel is the middle bit it works.
For me, the kernel is above userland. The computer is like a country and the kernel is like the goverment. It goes on top of userland for me.
Dr Clegg looks surprisingly similar to Tarantino!
Interestingly I am now finishing up my thesis and at one point I was using eBPF to solve a problem. It is such a powerful tool.
Always happy to see a new Dr Clegg video!
It's an amazing topic, I think it deserves a better videos
Brilliant explanation of eBPF and great introduction. Thank you!
When I first looked up “eBPF”, the “packet filtering” bit threw me off 😅. Explaining how this went from a simple packet filter to what eBPF is now was very helpful.
"Let's imagine you are working on..Linux - which everyone should be" - truer words were never apoken
That example looks very cool - I usually implement LuaJIT in my projects if i need any extensibility, but i have considered alternatives incl. BPF. It's probably too low level for my needs, but I may play around the example as I've never used BPF before.
I have used eBPF for my master thesis (CS) and while eBPF is extremely interesting for including project extensibility it has very serious limitations. The most important for general extensibility is that it has no floating point support. That said for program extensibility there are ready to go userspace eBPF VMs that you can easily include the most prominent is known as uBPF (I can't share links those comments get shadow banned on youtube).
@@DantalionNl sounds interesting, thank you 😊 dw about links, I found the uBPF project page.
Induct molz~tmp prnt LN''
Patton Oswalt is such a renaissance man.
The only thing more sustantial than the content of the video is the gesticulation :D
What can I say... can't talk without waving my hands. 😂
Fascinating stuff! Would be nice with another video going deeper on eBPF, looking into how we determine if a program is safe to run.
And yes ... everybody loves the Fibonacci sequence hehe
Importantly, the kernel verifier not only prevents guaranteed infinite loops, it also prevents any loops which can't be proven to be finite. That might seem like a trivial difference, but it means that the subset of "runnable" eBPF (as opposed to all compilable eBPF) is also not Turing complete, because you can't prove whether or not an arbitrary Turing machine holds, so if we only allow turing machines for which this is possible (i.e. equivalent automata of a higher Chomsky Type), we've excluded some possible programs.
I would have really liked a more in-depth look into eBPF bytecode in the video for that reason. As far as I know the verifier checks the programs control flow graph, and if that is not acyclic, rejects the program (consequently loops have to be unrolled by the compiler to be able to pass the verification). But I would have liked to know a bit more about the verification process, and what additionally goes into it.
I'm still glad you've shown this demo, thank you!
What stops me from writing acyclic code that will take longer than the lifetime of the universe to terminate? The entire idea sounds naive to me. Unless they are setting a low (1 minute) limit on top, without the ability to restart... and even then one can probably still do some rather malicious things with it.
loved this episode! gave me lots of ideas!
This is kind of missing the part of the video where he actually runs the infinite loop and sees what happens to the computer when a rogue kernel process actually runs... Still very interesting video, as someone who worked with userspace networking code (kind of going in the other direction with RDMA - moving all the TCP processing off to the NIC and utilizing userspace to do the rest), this BPF stuff is pretty neat!
You can not run an infinite loop with eBPF on Linux, all eBPF kernels need to be statically verifiable, you can not even use arguments for loop termination conditions. If the program is deemed not safe for execution the Linux kernel will refuse to run it.
@@h..hThere will be some configurable limit, typically not defined in loop iterations but in a amortized 'computational complexity' cost estimate based on the amount data moved, the calls made and the loop iterations as well as the number of branches
@@h..hSo it used to be you couldn’t even have bounded loops, but kernel version 5.3 allowed that. The big limit now is a maximum of 1 million instructions. The reason bounded loops are allowed is because the eBPF verifier will be able to expand the loop to determine the number of instructions it will take.
Of course, if you’re writing a program to run on kernel versions lower than 5.3, you can’t even have bounded loops, which I can say from experience is incredibly limiting
I think he wasnt expecting it to catch it
@@DantalionNlYeah but he literally managed to bypass the infinite loop check from the compiler didn't he? It's in the video.
I am very tired/Jetlagged and thought I was watching a Ronnie Barker video for a second there!
Its Fletch from Porridge! LEGEND! Nice to see he's finally going straight... 😂
Super interesting, I've never heard of this before. I see in the comments that there is even an intermediate compilation standard. Presumably that's something like JVM bytecode but for a kernel VM. I do have to wonder about security though. All the problems with virtual machines, now in your kernel!
This can be used for some very advanced stuff, pretty nice!
Justine Tunney used eBPF to make really easy-to-use process-level sandboxing on Linux, inspired by OpenBSD's pledge/unveil syscalls. I would paste a link but Google would eat my comment.
You mean seccomp?
Really cool stuff!
I'm getting bad flashbacks seeing BPF, XDP and other stuff like this, did some work with that and it was a real pain, although mostly because of the custom kernel and NIC drivers.
It used to be particularly difficult to get working right but there has been a lot of consolidation of the number of available runtime frameworks, the runtimes are typically incompatible with one another making the experience pretty hard to understand and use. Especially now that LLVM can compile bytecode and that we have BTF, a system to help make the bytecode work regardless of Linux kernel version, things have settled quite a bit.
I didn't find it too awful. I learned to code it for this video. Compared to (say) DPDK it is low effort to learn.
@@richardclegg8027 well I was pairing it with dpdk but only for development purposes
it's still c promotional rules, bpf has a known word size, untyped variables are ints, changing it to u64 is probably the same resulting type
The verifier runs C promotional rules? Even weirder then it changes the outcome.
Great, more!
Looks like a great tool for hackers wanting to implement persistent attacks!
😂
A common topic during blackhat and defcon for the last years indeed, although making them undetectable and persistent is actually particularly hard. Especially since the events registered can be easily queried and the events are cleared every time the system reboots.
I had not thought too much about it when I was asked. *But* if I am running some code a hacker wrote then I already kind of lost right. :)
This is so weird, I just learned about eBPF like a week ago and got really interested in it and started writing some toy programs with it to get a feel for it.
So seeing a Computerphile video uploaded just now is kinda creepy.
I build my own kernels, and I never include anything BPF in them. Same goes for IPv6, Bluetooth, WiFi, initrd and so on. All of a sudden the kernel is a mere 5 MB - instead 100MB plus kernel objects plus initrd.
Very informative - lots going on under the covers. A rich potential attack vector? Or not, if the eBPF code has to run as root?
You can do anything as root
@@StefanReich Which is just as bad an idea as this. A user machine should NEVER allow root access.
@@lepidoptera9337So, sudo shouldn't be allowed under any circumstances?
@@tablettablete186 sudo is a naive workaround for the failed "root" concept. The average user should NEVER have to use it. Look, all of this was invented at a time when computer security was not a problem. Today it is. Nobody was doing their bank transactions on a multi-user mainframe in the 1960s and early 1970s. Except for the bank, that is... and they could physically secure their hardware and the only possible "hackers" were their own employees who had hardware access. That made these simple minded concepts somewhat workable. They are not workable today.
Very nice 👌
Why not load the custom kernel module for this?
Would love to see a video on this by somebody who really knows the topic.
It can detect infinite loops - that's insane
What if you modify the compiler to allow malicious code?
Doesn't matter, the kernel itself does the final verification on the compiled eBPF bytecode.
The Linux eBPF verifier will determine that your program is not statically verifiable and not run it. All eBPF programs need to be statically verifiable by the Linux kernel prior to execution. The static verification also checks for things like guaranteed termination of the program, so you can't use arguments in loop counters for instance.
@DantalionNl the verification isn't to stop malicious code, it's to stop you from bricking your OS by accidentally looping forever in kernel space.
You need yo be root or have the CAP_BPF capability to inject eBPF code. It's assumed you will only be granted that permission if you're a trusted user.
So if a program require a kernel feature but my kernel isn't compiled with that feature I could use eBPF to essentially run the program without the need of recompiling the kernel with necessary feature?
Mostly no, eBPF programs (in Linux) can only run as events based on what the kernel is doing so whenever a packet arrives on a specific interface. However, you could never run it as a driver for the network interface in the first place. So similarly you can register events on filesystem operations but can't implement the filesystem itself.
Sort of depends what you mean by feature. If your kernel is not monitoring something at all you can't make it do so using eBPF. But if you want a higher level feature that you can derive from other features then you could in theory.
I love hearing the Brits, their accents are so posh!
The correct ways to monitor use of a kernel function on Linux is ftrace. Ideally systemtap would work but in my experience it doesn’t. Dtrace on the other has always worked as documented (on those platforms). For general code write a module.
Module is kind of a half way house but it is a lot if all you want to do is (say) write a little monitoring program. Plus now your user needs a module installed for your monitor and then they need another module for the next person's monitor and so on and so on... pretty soon they got ten extra modules in their kernel.
Not a computer scientist, but as far as I can tell this is less about monitoring the use of the kernel and more about using the kernel to monitor something external to the kernel, eg a hardware interface of some sort. This kind of makes sense given that it's built out from a network interface monitor, and certainly to say that it's "incorrect" when it's broadly used in practice would seem to render the term "incorrect" somewhat meaningless.
I never realised NICs could run BPF
Not only NICs but also storage systems such as NVMe SSDs, this is known as Computational Storage and has been the topic of my masters thesis.
It is pretty cool. Not sure how widespread.
@@DantalionNl Sounds super interesting. Maybe we'll see you on Computerphile one day.
NICs can run entire linux distros
I am interested in learning kernel programming.Can anyone suggest where to begin.
ok, but if it's so limited, why this weird C syntax ? - Why not something simple? Or Zig like even? (that has built in maximal stack depth, etc.)
Why would a fibonacci number with N larger than 40 overflow? He was using 64 bit unsgined integers so the limit would be over 18446744073709551615, which is between N=92 and N=93
eBPF controls the Kernel, like an arduino controls a LCD display. This type of technology should be called "Controlling the Kernel as a toy" 🤖
can you do a video on io_uring please
What implications does it have on security?
It kills it. ;-)
17:00 -- So basically the same as everything else on Linux then?
What is that drawing on his wall?
That white IDE theme is criminal; not only is it blindingly bright but also regular code and comments have the same color 🤣
That's because the whole program is a string literal, so it's not formatted
Exactly as Magnus below said. The IDE correctly colours the "code" in C as if it is a string because it is a string. It colours the python correctly.
The immediate 2 questions I have are:
Did they solve the halting problem?
And have you tried expressing recursion in terms of the Y combinator?
You really need to be careful with your language design when you want to guarantee all programs in it will terminate.
it's a finite program
It is kind of the opposite of the halting problem. Knowing what class of programs halt is hard. But specifying a subset of programs that definitely halt is easy.
You can workaround the halting problem with how static analysis does it: it's considered non-halting if it can't prove that it halts
!?!
The immediate 2 questions I have are:
- What does solving the halting problem have to do with eBPF ?
- Why recursion, and expressing it with the Y combinator is so important for monitoring an OS?
It's just an embedded language for a very niche application, not haskell.
One minor correction at 6:04: I think you're referring to XDP, not XDF.
Is this the same as system hooks in windows?
So you can use Python for EBPF but is not possible with Golang
I am sure you can use any language with a C FFI the way Python is used here. The actual eBPF code is in C, but Rust (and apparently others) can be used. Go needs a runtime, so it can't be the actual eBPF program. (It would be too big for the verifier to accept)
"... let's imagine you're on linux, which everybody should be..."
nice video!
@NumberOneRated1997 haha, you are quite a funny guy (not saying it in a sarcastic way).
wouldn't this (from your example) still run into the problem of that you can't tell if a program will run forever due to the halting problem?
Solving the halting problem would be having a compiler that states whether a program halts or not. What this compiler says is either 'yes, this program halts', or 'I can't say anything about whether it halts or not'. If the compiler can't say anything then the program is treated as if it was non-halting and is not allowed to run in the kernel.
I really hope that it doesn't become anything like what JavaScript is for the Web.
Hah... I am afraid it is a common analogy. JavaScript but for kernel is how people talk about it at conference.
Given the limitations of eBPF programs, there is little risks of that happening.
The only commonality eBPF bears with JavaScript is they both run on VMs, this is it.
eBPF is more like the kernel WASM rather.
@@richardclegg8027 What an awful analogy - I wish they didn't.
I'm glad I managed to learn about this before I heard the analogy - well, perhaps the video mentioned it, but it showed what it _really_ was like, and it was nothing like that analogy. I hope someone at these conferences would hold a speech about why this analogy might be better left out.
When I hear _"like Javascript, but for kernel",_ it immediately raises a crapton of red flags in my mind.
But when I saw this video I actually thought of it as quite cool technology with potential when used the right way.
How does this compare to microkernel where most things are in user space?
Latency/security tradeoff
This thing is designed for monitoring purposes, this is not kernel module replacement.
Also, afaik microkernel modules don't run in userspace. They just isolated from kernel so you can't crash a kernel with null pointer dereference.
For me the key point of the microkernel is that the machine is specialized only to do very specific things.
@@richardclegg8027 Agreed.
DKMS is another solution, though not as portable
"what javascript is to the web"
... a mistake?
I think there's a guy whom the devs can ask about whether their "infinite loop detection" system can ever work. Name was Kurt Gödel, if I remember correctly.
TempleOS is always ring 0 baby
CROWDSTRIKE WAS HERE. Class action lawsuit.
eBPF IS THE BEST THING EVER BUT WITH THE WORST DEVELOPMENT EXPERIENCE 😩😩
eBPF appeals to the masochist in me
Hah... a bit extreme. Some technology is far harder to get a working build going. But yes, it was not quite as easy as I hoped.
This isn't kernel-less as it's still very much using the kernel.
ChatGPT thinks they should call it KernelScript.
Question: is there any reason to do this in python, or is it because the original code that used python for logic and sorting/filtering of data?
Without knowing how much stuff the python class does on the background, it seems like a method to circumvent any help your IDE could offer for writing C, which sounds like a bad time.
But if the python-class is doing some magic on the background, writing this in C directly could be much more code than shown here.
Python is pretty easy for people on the channel to read. You could write in a lot of languages.
The python part of the code does not need to be highly optimized.
Wow, so this is a fully fledged Linux backdoor, then? How can this be safe at all? Surely there must be exploits that can bypass whatever heuristic they have that prevents compiling and running malicious code.
How is this a backdoor? You must be root to insert any ebpf code, at that point you hahve full control anyway.
@@alpo789 I never understood why people think that "root" is safe. For 99% of users it's more likely that the hacker knows how to become root before the user does.
Wait, you're telling me that the developers of BPF haven't managed to solve the halting problem?
They don't need to solve the halting problem. They need to specify a subset of programs that definitely halt. It is kind of the opposite of the halting problem.
They rule out some program which would be fine to run and would halt in time.
@@richardclegg8027 Right, that makes sense. Although even that couldn't prevent an algorithm that eventually halts but does so after an inordinate amount of time. Unless... maybe if you constrain what kinds of loops are allowed somehow? Or just not allow loops at all?
@@pv2b I'm not honestly sure at that point. If you want to look it up you can look up the eBPF verifier. I thought about the same myself before making this but the video was getting long already.
Martin Anthony Jones Robert Perez Donna
Gee .. Linux developers discovered DTrace😄
Why is someone who doesn't know much about eBPF is explaining it to other people?
Because this is the internet? ;-)
Too slow, man - I'm up to 3:40 and you still haven't gotten to the POINT of what eBPF actually is. You just made me curious, so I've gone now to look it up elsewhere...
Smith Sarah Thomas Laura White Jeffrey
Ah yes the human utopian dream. Doing something without actually doing it.
bro is zesty
first
@NumberOneRated1997 what is wrong with you
@NumberOneRated1997 TH-cam isn't the place for creepy roleplaying. Maybe find some friends online to do that with so you aren't spamming up someone's channel, yeah?
So in short it's a MAJOR security flaw that needs to be patched pronto
Actually, it is used to make the systems more secure than not.
You could make a cruel prank where whatever file is open, you could randomly inject extra characters that is returned to the user
Love the idea. Or when someone does an ls to find the file you move it.
@@richardclegg8027 or write it to whatever is the equivalent of /dev/dsp nowdays