> Back when "put everything in the kernel to make it fast" was the forefront of computing technology.
Linux kernel/bpf is getting nervous.
joking aside (and sorry for going off on this tangent) under Linux it seems the kernel is eating more of user-space every year. That argument could of course be also turned around by claiming that user-space is eating the kernel. which ever way you look at - systems programming has gotten much more challenging (interesting) in the past years.
I guess I don't see it that way. Probably the hairiest things in the kernel that maybe shouldn't be there are boot-time network filesystems, but I think that's kinda the price you pay for that sort of convenience.
bpf is a sandbox, and unprivileged processes do not magically gain access to it; anything malicious that could be done with bpf could as easily be done with the coincident root privileges.
What is your example of where the Linux kernel is "eating more of user space every year"?
> I guess I don't see it that way. Probably the hairiest things in the kernel that maybe shouldn't be there are boot-time network filesystems, but I think that's kinda the price you pay for that sort of convenience.
Unprivileged processes can load bpf filters though - they can attach filters to sockets or load seccomp syscall filters, to name two examples. Just because it is a sandbox doesn’t mean that loading and executing user-supplied code in kernel mode is free from risk! I’m sure the Microsoft engineers thought their code was bulletproof too right until the exploits started showing up.
Heck, the entire io_uring system is a prime example of the Linux kernel “eating more of user space” - it’s essentially a programmable syscall pipeline that executes entirely in kernel mode. All to reduce some user/kernel transitions - exactly why ATMFD and http.sys were invented in the Windows kernel.
> exactly why ATMFD ... [was] invented in the Windows kernel
Except everything ATMFD does is basically obsolete if you have memory mapped files. FreeType works fine, nobody ever tried to put it in the kernel (at least upstream, in a form accessible to userspace).
But bpf(2) isn't the only entry point for bpf filters in the kernel. Unprivileged user programs have access to the SOL_SOCKET SO_ATTACH_FILTER sockopt, as well as the PR_SET_SECCOMP SECCOMP_MODE_FILTER prctl. Now, these take cBPF programs, not eBPF - so they don't have all the fancy programming features that bpf(2) has - but they're still "code running in the kernel".
> What is your example of where the Linux kernel is "eating more of user space every year"?
to clarify I love ebpf traffic processing as opposed to having an iptables nfqueue[1] based approach (or worse a fully privileged kernel module).
my point was that userspace now looks different than before because I have to gain a pretty deep understanding of LLVM in order to do meaningful work to achieve the same goal (and be rewarded by a ~50% speed up).
Is ebpf user-space? Is it kerne-space? Is it something inbetween? I've written C for over 2 decades and have used assembler to optimize for embedded architecture where it made sense. far from an expert in assembler - maybe I'm not a good systems programmer because I should know more about this topic?
[1] I wrote this in January: https://github.com/DyslexicAtheist/nfq/ fully aware it could be done in ebpf but chose NFQ nevertheless - because my LLVM foo is simply not good enough. I feel either I'm dumb or the learning-curve is so big that it will take me a year or more to get the same done in ebpf. So ebpf has in some way hi-jacked my existing user-land skills :) not complaining - just saying my skill set has been obsoleted in a matter of few months - again not complaining - I will just have to dig deeper into LLVM and know more about the hardware than I did before :)
____
really don't understand where the downvotes are coming from since I haven't criticized the current approach. it seems HN is a bad place to make a joke.
> Probably the hairiest things in the kernel that maybe shouldn't be there are boot-time network filesystems, but I think that's kinda the price you pay for that sort of convenience.
I don't call having to tweak my kernel config to be very convenient, or the graphics driver crashing my system, or not having an obvious way to reboot the network/audio/FS stacks without doing a full reboot (I am sure it may be possible).
However, I am hardly the target market for gnu/linux.
Linux kernel/bpf is getting nervous.
joking aside (and sorry for going off on this tangent) under Linux it seems the kernel is eating more of user-space every year. That argument could of course be also turned around by claiming that user-space is eating the kernel. which ever way you look at - systems programming has gotten much more challenging (interesting) in the past years.