4 ms·

DTrace and eBPF are "not so different" in the sense that dtrace programs / hooks are also a form of low-level code / instruction set that the kernel (dtrace dri

by fch42 2y ago

DTrace and eBPF are "not so different" in the sense that dtrace programs / hooks are also a form of low-level code / instruction set that the kernel (dtrace driver) validates at load. It's an "internal" artifact of dtrace though, https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libdtrace/common/dt_cc.c https://github.com/illumos/illumos-gate/blob/master/usr/src/... and to my knowledge, nothing like a clang/gcc "dtrace target" exists to translate more-or-less arbitrary higher-level language "to low-level dtrace". The additional flexibility eBPF gets from this is amazing really. While dtrace is a more-targeted (and for its intended usecases, in some situations still superior to eBPF) but also less-general tool. (citrus vs. stone fruit ...)

cryptonector 2y ago
DTrace's bytecode machine is also very very limited. eBPF's is much less limited. Limiting the scope of what a probe can do is very important.
- bcantrill 2y ago
  Yes, thank you. Long before eBPF existed, we spent a ton of time on the safety of DTrace[0][1] -- there's a bunch of subtlety to it. The proof is in the pudding, however: thanks to our strict adherence to the safety constraint, we have absolute confidence in using DTrace in production. [0] https://bcantrill.dtrace.org/2005/07/19/dtrace-safety/ https://bcantrill.dtrace.org/2005/07/19/dtrace-safety/ [1] https://www.usenix.org/legacy/publications/library/proceedings/usenix04/tech/general/full_papers/cantrill/cantrill.pdf https://www.usenix.org/legacy/publications/library/proceedin..., §3.3
  - saagarjha 2y ago
    I’m curious which part of these tenets would feel would have prevented the bug demonstrated, besides “oh we tried harder”? I don’t see any of those that seem unique to DTrace other than limiting where probes can be placed.
    - cryptonector 2y ago
      The DTrace bytecode VM is simply more limited: - it cannot branch backwards (this is also true of eBPF) - it can only do ternary operator branches - it cannot define functions - functions it can call are limited to some builtin ones - it can only scribble on the one pre-allocated probe buffer - it can only access the probe's defined parameters
      - tptacek 2y ago
        eBPF programs can absolutely branch backwards. You may be thinking of cBPF.
        cryptonector 2y ago
        I was thinking of the original BPF. I didn't realize that eBPF added back branching.
        tptacek 2y ago
        If the verifier can prove to itself that a loop is bounded, it'll accept it. A good starting place for eBPF itself: if a normal ARM program could do it, eBPF can do it. It's a fully functional ISA.
        cryptonector 2y ago
        I'm w/ the DTrace guys on this. A turing complete VM is a bad idea for this purpose.
        tptacek 2y ago
        It depends on what you're using it for. If you want to expose this to untrusted code, yes, but I wouldn't be comfortable doing that with DTrace either.
        2y ago
- rurban 2y ago
  DTrace does not have arrays on purpose because they reasoned that those bounds checks will not be secure. And DTrace provides seemless tooling up into user-space scripts. Kernel, libc, scripts. Until eBPF came around and said we can now prove it to be secure. Until the sidechannel hackers came around to prove the opposite.

by fch42 2y ago

cryptonector 2y ago

DTrace's bytecode machine is also very very limited. eBPF's is much less limited. Limiting the scope of what a probe can do is very important.

bcantrill 2y ago
Yes, thank you. Long before eBPF existed, we spent a ton of time on the safety of DTrace[0][1] -- there's a bunch of subtlety to it. The proof is in the pudding, however: thanks to our strict adherence to the safety constraint, we have absolute confidence in using DTrace in production. [0] https://bcantrill.dtrace.org/2005/07/19/dtrace-safety/ https://bcantrill.dtrace.org/2005/07/19/dtrace-safety/ [1] https://www.usenix.org/legacy/publications/library/proceedings/usenix04/tech/general/full_papers/cantrill/cantrill.pdf https://www.usenix.org/legacy/publications/library/proceedin..., §3.3
- saagarjha 2y ago
  I’m curious which part of these tenets would feel would have prevented the bug demonstrated, besides “oh we tried harder”? I don’t see any of those that seem unique to DTrace other than limiting where probes can be placed.
  - cryptonector 2y ago
    The DTrace bytecode VM is simply more limited: - it cannot branch backwards (this is also true of eBPF) - it can only do ternary operator branches - it cannot define functions - functions it can call are limited to some builtin ones - it can only scribble on the one pre-allocated probe buffer - it can only access the probe's defined parameters
    - tptacek 2y ago
      eBPF programs can absolutely branch backwards. You may be thinking of cBPF.
      - cryptonector 2y ago
        I was thinking of the original BPF. I didn't realize that eBPF added back branching.
        tptacek 2y ago
        If the verifier can prove to itself that a loop is bounded, it'll accept it. A good starting place for eBPF itself: if a normal ARM program could do it, eBPF can do it. It's a fully functional ISA.
        cryptonector 2y ago
        I'm w/ the DTrace guys on this. A turing complete VM is a bad idea for this purpose.
        tptacek 2y ago
        It depends on what you're using it for. If you want to expose this to untrusted code, yes, but I wouldn't be comfortable doing that with DTrace either.
        2y ago
rurban 2y ago
DTrace does not have arrays on purpose because they reasoned that those bounds checks will not be secure. And DTrace provides seemless tooling up into user-space scripts. Kernel, libc, scripts. Until eBPF came around and said we can now prove it to be secure. Until the sidechannel hackers came around to prove the opposite.