3 ms·

> In the future, computers will not crash due to bad software updates, even those updates that involve kernel code. In the future, these updates will push eBPF

by xg15 2y ago

> In the future, computers will not crash due to bad software updates, even those updates that involve kernel code. In the future, these updates will push eBPF code. Assuming every security critical system will be on a recent enough kernel to support this...

efee22 2y ago
I think with a LTS distribution you should get very far these days when it comes to implementing such sensors.
- chasil 2y ago
  On rhel8 variants, you can use the Oracle UEK to get eBPF. https://blogs.oracle.com/linux/post/oracle-linux-and-bpf https://blogs.oracle.com/linux/post/oracle-linux-and-bpf $ cat /etc/redhat-release /etc/oracle-release /proc/version Red Hat Enterprise Linux release 8.10 (Ootpa) Oracle Linux Server release 8.10 Linux version 5.15.0-203.146.5.1.el8uek.x86_64 (mockbuild@host-100-100-224-48) (gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9.2.0.1), GNU ld version 2.36.1-4.0.1.el8_6) #2 SMP Thu Feb 8 17:14:39 PST 2024
dijit 2y ago
And assuming there's no bugs in the BPF code... Oh wait: https://news.ycombinator.com/item?id=41031699 https://news.ycombinator.com/item?id=41031699
- efee22 2y ago
  RHEL kernel.. right. Imho, I'd trust an upstream stable kernel far more than a RHEL one for production which has dozen of feature backports and an internal kABI to maintain.. granted RH has a QA team, but it is still impossible to test everything beforehand.
  - worthless-trash 2y ago
    On the upside, non root users can't insert ebpf code, so its a priv'ed operation, not like other distros.
    - nequo 2y ago
      Isn’t it tied to CAP_BPF on every distro since the 5.8 kernel? https://mdaverde.com/posts/cap-bpf/ https://mdaverde.com/posts/cap-bpf/
      - worthless-trash 2y ago
        Rhel8 is based on 4.18 RHEL9 is based on 5.14 , i think it still has the same restriction ( kernel.unprivileged_bpf_disabled ). I reckon Red Hat may duplicate upstreams behavior by RHEL10.
dredmorbius 2y ago
Considering the number of systems running very obsolete OSes these days: WinNT (4x or 3x), Windows, DOS, or various proprietary Unixen, stale Linux flavours, etc., etc., ... yes, quite.

by xg15 2y ago

efee22 2y ago

I think with a LTS distribution you should get very far these days when it comes to implementing such sensors.

chasil 2y ago
On rhel8 variants, you can use the Oracle UEK to get eBPF. https://blogs.oracle.com/linux/post/oracle-linux-and-bpf https://blogs.oracle.com/linux/post/oracle-linux-and-bpf $ cat /etc/redhat-release /etc/oracle-release /proc/version Red Hat Enterprise Linux release 8.10 (Ootpa) Oracle Linux Server release 8.10 Linux version 5.15.0-203.146.5.1.el8uek.x86_64 (mockbuild@host-100-100-224-48) (gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9.2.0.1), GNU ld version 2.36.1-4.0.1.el8_6) #2 SMP Thu Feb 8 17:14:39 PST 2024

dijit 2y ago

And assuming there's no bugs in the BPF code... Oh wait: https://news.ycombinator.com/item?id=41031699 https://news.ycombinator.com/item?id=41031699

efee22 2y ago
RHEL kernel.. right. Imho, I'd trust an upstream stable kernel far more than a RHEL one for production which has dozen of feature backports and an internal kABI to maintain.. granted RH has a QA team, but it is still impossible to test everything beforehand.
- worthless-trash 2y ago
  On the upside, non root users can't insert ebpf code, so its a priv'ed operation, not like other distros.
  - nequo 2y ago
    Isn’t it tied to CAP_BPF on every distro since the 5.8 kernel? https://mdaverde.com/posts/cap-bpf/ https://mdaverde.com/posts/cap-bpf/
    - worthless-trash 2y ago
      Rhel8 is based on 4.18 RHEL9 is based on 5.14 , i think it still has the same restriction ( kernel.unprivileged_bpf_disabled ). I reckon Red Hat may duplicate upstreams behavior by RHEL10.

dredmorbius 2y ago

Considering the number of systems running very obsolete OSes these days: WinNT (4x or 3x), Windows, DOS, or various proprietary Unixen, stale Linux flavours, etc., etc., ... yes, quite.