4 ms·

Hmm I think bpf today is used in fully trusted environments. Kernel level verification is unnecessary except in untrusted containerized environments or when run

Hmm I think bpf today is used in fully trusted environments. Kernel level verification is unnecessary except in untrusted containerized environments or when running untrusted applications, both use cases being relatively rare/specialized. I think the main benefit of bpf is that it prevents you from shooting yourself in the foot. Running totally untrusted code in the kernel just seems like a recipe for disaster and for that reason it makes sense bpf is still limited to root.

monocasa 7y ago
That's where it is today, but the end goal is removing that restriction. It probably would have happened quicker if Spectre/Meltdown hadn't come out of nowhere. Like it used to be that KVM required CAP_SYS_ADMIN as well, but now that's been opened up to whoever has permissions to the device file. Start requiring "own the box anyway" privileges while the feature bakes, but open it up as it becomes more mature and attackers have a go at it. It's sort of like how originally you could only jump forward, then the opened it up to any DAG, then they allowed probably bounded loops. And there's been OSes that don't require root for their in kernel virtual machines, XOK and AEGIS being the prominent examples.
- manyworlds 7y ago
  Sure but I don’t see any compelling use cases to motivate opening it up. Do you have an example of one? Even if the kernel opens it up without a compelling use case, it seems likely that distribution policy will keep it default locked to root. Which is my point here. I don’t see a compelling reason to have a JIT in the kernel when AOT BPF seems to cover 90% of all existing use cases. In fact I may even write a bpf to kernel module compiler myself.
  - monocasa 7y ago
    * Syscall tracing, sandboxing, and monitoring * KVM device MMIO emulation * OS personality emulation (like WSL but doesn't require root) * New synchronization primitives to user space (like XOK's wake predicates) * A lot of others.. Modern BPF is the exploring the same cornerstones as exokernels and really opens up a whole bunch of concepts that haven't been seen in mainstream kernels, particularly if non privileged users are allowed to invoke it.
    - manyworlds 7y ago
      Thanks for the examples but those all still seem like things vast majority of Linux users can do today, since vast majority of Linux users have root access. Both desktop and server. Mobile users like android don’t have root but I don’t see why an untrusted mobile app would need bpf. Only benefit of allowing non-root that I can see is enabling untrusted containers in cloud environments to do the same. All large cloud providers use KVM/zen (not containers) for untrusted users in which case they already have root. Can you give an example of a scenario where the user doesn’t have root yet still would want to do those things?

monocasa 7y ago

That's where it is today, but the end goal is removing that restriction. It probably would have happened quicker if Spectre/Meltdown hadn't come out of nowhere. Like it used to be that KVM required CAP_SYS_ADMIN as well, but now that's been opened up to whoever has permissions to the device file. Start requiring "own the box anyway" privileges while the feature bakes, but open it up as it becomes more mature and attackers have a go at it. It's sort of like how originally you could only jump forward, then the opened it up to any DAG, then they allowed probably bounded loops. And there's been OSes that don't require root for their in kernel virtual machines, XOK and AEGIS being the prominent examples.

manyworlds 7y ago
Sure but I don’t see any compelling use cases to motivate opening it up. Do you have an example of one? Even if the kernel opens it up without a compelling use case, it seems likely that distribution policy will keep it default locked to root. Which is my point here. I don’t see a compelling reason to have a JIT in the kernel when AOT BPF seems to cover 90% of all existing use cases. In fact I may even write a bpf to kernel module compiler myself.
- monocasa 7y ago
  * Syscall tracing, sandboxing, and monitoring * KVM device MMIO emulation * OS personality emulation (like WSL but doesn't require root) * New synchronization primitives to user space (like XOK's wake predicates) * A lot of others.. Modern BPF is the exploring the same cornerstones as exokernels and really opens up a whole bunch of concepts that haven't been seen in mainstream kernels, particularly if non privileged users are allowed to invoke it.
  - manyworlds 7y ago
    Thanks for the examples but those all still seem like things vast majority of Linux users can do today, since vast majority of Linux users have root access. Both desktop and server. Mobile users like android don’t have root but I don’t see why an untrusted mobile app would need bpf. Only benefit of allowing non-root that I can see is enabling untrusted containers in cloud environments to do the same. All large cloud providers use KVM/zen (not containers) for untrusted users in which case they already have root. Can you give an example of a scenario where the user doesn’t have root yet still would want to do those things?