3 ms·

It seems like the biggest counterargument to this would be the one made in https://www.brendangregg.com/blog/2024-07-22/no-more-blue-fridays.html https://www.br

by twiss 2y ago

It seems like the biggest counterargument to this would be the one made in https://www.brendangregg.com/blog/2024-07-22/no-more-blue-fridays.html https://www.brendangregg.com/blog/2024-07-22/no-more-blue-fr... (https://news.ycombinator.com/item?id=41033579 https://news.ycombinator.com/item?id=41033579), i.e. it should be possible to provide a safe API (like eBPF) to provide the access that third-party security apps need, without risking crashes.

bilbo0s 2y ago
I don’t know man? At some level, we would have to accept that if we’re giving people, many of them hackers, access to kernel level facilities, there is a risk involved. If you want no risk, use a walled off OS. If you want a more flexible or permissive kernel architecture, then accept that the burden of securing it is kind of on you after a point. Put in layman’s terms, I can put that riving knife on your table saw, but there’s still a risk to using it. It’s just a risky tool.
- layer8 2y ago
  Ebpf provides exactly that wall.
  - bilbo0s 2y ago
    Sigh. Guys, eBPF provides more limited access to kernel features. That’s by design. Whatever the platform, the idea with eBPF is to limit kernel access and provide safe access only where ‘necessary’. The entire issue is that MS limited access to their kernel. If you want the people who use eBPF, windows developers, to have the same access to kernel features as the providers of eBPF facilities, MS themselves, then you’re effectively giving them kernel access. There is no such thing as safe full featured kernel access.
    - freeopinion 2y ago
      I personally don't have problems with developers having kernel access. I can't imagine any open source OS fan objecting to this. I do have problems with MS or any other vendor using kernel access unnecessarily. MS Paint should not run in the kernel. Just because you can doesn't mean you should. The question is whether MS or any other vendor could provide the feature set their product enjoys without running in the kernel. If Windows offered anything like eBPF but MS security apps chose to run in-kernel instead of through eBPF, then MS should be forced to give competitors the same kernel access. If MS would play fair and restrict their non-OS teams to userspace they wouldn't have to play fair by providing access to kernelspace. The argument is that it is impossible for MS non-OS teams to play in userspace because MS doesn't provide the APIs to make it possible. It seems that some other OSes might not suffer from this deficiency.

by twiss 2y ago

bilbo0s 2y ago

I don’t know man? At some level, we would have to accept that if we’re giving people, many of them hackers, access to kernel level facilities, there is a risk involved. If you want no risk, use a walled off OS. If you want a more flexible or permissive kernel architecture, then accept that the burden of securing it is kind of on you after a point. Put in layman’s terms, I can put that riving knife on your table saw, but there’s still a risk to using it. It’s just a risky tool.

layer8 2y ago
Ebpf provides exactly that wall.
- bilbo0s 2y ago
  Sigh. Guys, eBPF provides more limited access to kernel features. That’s by design. Whatever the platform, the idea with eBPF is to limit kernel access and provide safe access only where ‘necessary’. The entire issue is that MS limited access to their kernel. If you want the people who use eBPF, windows developers, to have the same access to kernel features as the providers of eBPF facilities, MS themselves, then you’re effectively giving them kernel access. There is no such thing as safe full featured kernel access.
  - freeopinion 2y ago
    I personally don't have problems with developers having kernel access. I can't imagine any open source OS fan objecting to this. I do have problems with MS or any other vendor using kernel access unnecessarily. MS Paint should not run in the kernel. Just because you can doesn't mean you should. The question is whether MS or any other vendor could provide the feature set their product enjoys without running in the kernel. If Windows offered anything like eBPF but MS security apps chose to run in-kernel instead of through eBPF, then MS should be forced to give competitors the same kernel access. If MS would play fair and restrict their non-OS teams to userspace they wouldn't have to play fair by providing access to kernelspace. The argument is that it is impossible for MS non-OS teams to play in userspace because MS doesn't provide the APIs to make it possible. It seems that some other OSes might not suffer from this deficiency.