6 ms·

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

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"?

blattimwind 7y ago
> 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. X.509 parsers... or three or so...
nneonneo 7y ago
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.
- microcolonel 7y ago
  > 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).
- threentaway 7y ago
  > Unprivileged processes can load bpf filters though No they can't. Calling bpf(2) requires you to be running as root or have CAP_SYS_ADMIN.
  - taviso 7y ago
    You're forgetting CONFIG_USER_NS, like it or not, it's ubiquitous now.
    - cyphar 7y ago
      Using eBPF requires CAP_SYS_ADMIN in the host user namespace. Unprivileged user namespaces don't help.
  - nneonneo 7y ago
    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".
- heavenlyblue 7y ago
  > I’m sure the Microsoft engineers thought their code was bulletproof too right until the exploits started showing up. I am sure the engineers at Microsoft were shipping and not thinking about exploits. Or at least the exploits were the lesser of their worries.
monadic2 7y ago
> 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.
DyslexicAtheist 7y ago
> 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/ 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.

blattimwind 7y ago

> 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. X.509 parsers... or three or so...

nneonneo 7y ago

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.

microcolonel 7y ago
> 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).
threentaway 7y ago
> Unprivileged processes can load bpf filters though No they can't. Calling bpf(2) requires you to be running as root or have CAP_SYS_ADMIN.
- taviso 7y ago
  You're forgetting CONFIG_USER_NS, like it or not, it's ubiquitous now.
  - cyphar 7y ago
    Using eBPF requires CAP_SYS_ADMIN in the host user namespace. Unprivileged user namespaces don't help.
- nneonneo 7y ago
  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".
heavenlyblue 7y ago
> I’m sure the Microsoft engineers thought their code was bulletproof too right until the exploits started showing up. I am sure the engineers at Microsoft were shipping and not thinking about exploits. Or at least the exploits were the lesser of their worries.

monadic2 7y ago

> 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.

DyslexicAtheist 7y ago

> 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/ 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.