4 ms·

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 i

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.

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.