4 ms·

If anybody is interested I wrote a go-only library to interact and create ebpf programs. It even parses the compiled elf binary for you and maps it to your vari

If anybody is interested I wrote a go-only library to interact and create ebpf programs. It even parses the compiled elf binary for you and maps it to your variable names: https://github.com/nathanjsweet/ebpf https://github.com/nathanjsweet/ebpf

UncleEntity 9y ago
> However, eBPF opcode programs themselves must be governed by the GPLv2 anyways, so if you are distributing any software relying on this project you will probably be open-sourcing the most important part (the eBPF opcode) anyways. Really? That seems a bit harsh...
- hacknat 9y ago
  Not my decision sorry. If you are using them for some kind of server side tech then you’re probably in the clear, but if you are distributing any eBPF code you write to a consumer (think IoT) then you’ll have to think about it.
  - UncleEntity 9y ago
    I'm just surprised they would impose that restriction in the kernel considering they have very little problem with closed-source binary blobs for drivers and whatnot.
    - hacknat 9y ago
      Firmware can be closed source, but I’m fairly certain you have to open source the drivers too.
      - monocasa 9y ago
        It's grey area. For instance, Nvidia's probably safe with their closed source driver. Since their driver was originally for Windows and simply ported to Linux mainly via an abstraction layer, it'd be pretty difficult to prove to a judge that they're 'derived from' the Linux codebase.
        bonzini 9y ago
        It's not "being derived from", it's "being a derivative of", which in turn has a legal meaning that need not exactly coincide with the usual English meaning. That said, lawyers have certainly given their approval to the way Nvidia packages their driver, so it should be fine or at least very very hard to challenge.
    - icebraining 9y ago
      Apparently you can now load non-GPL licensed eBPF programs, but they can't then access certain functions marked as "GPL only". This matches the behavior for kernel modules.
      - hacknat 9y ago
        Interesting. @icebraining, do you know where this list exists?
        drzaeus77 9y ago
        The helpers are in http://elixir.free-electrons.com/linux/v4.15-rc3/source/kernel/bpf/helpers.c http://elixir.free-electrons.com/linux/v4.15-rc3/source/kern.... See the field gpl_only. For the list of which helpers are available in which hooks, the code needs to be read, to find things like: http://elixir.free-electrons.com/linux/v4.15-rc3/source/net/core/filter.c#L3357 http://elixir.free-electrons.com/linux/v4.15-rc3/source/net/.... Unfortunately, I don't believe the high level list of which hooks have gpl helpers is published, so reading the code is the best method currently.
        qeole 9y ago
        This list is under progress. Didn't think about adding licensing information for the helpers, but that's an excellent idea!
      - drzaeus77 9y ago
        The first BPF programs (original tcpdump use case) were always proprietary-compatible. If you think about it, there is nothing linux-specific about networking, and any code the user writes to tweak the data that is traversing their machine should be theirs to write, and doesn't taint the kernel. The same can be said for iptables/nft rules (you don't have to GPL your firewall configuration). Therefore, the BPF hooks that deal with packets (XDP, tc, socket) are not GPL-restricted and will remain so in the future. Where GPL comes in is when you use BPF to introspect the kernel. It is quite possible to use BPF programs with the kprobe hook to extract data about how the kernel itself works, and the opinion of the kernel developers on this is that such use cases are within the realm of GPL protection.
- deleted 9y ago
  [deleted]

UncleEntity 9y ago

> However, eBPF opcode programs themselves must be governed by the GPLv2 anyways, so if you are distributing any software relying on this project you will probably be open-sourcing the most important part (the eBPF opcode) anyways. Really? That seems a bit harsh...

hacknat 9y ago
Not my decision sorry. If you are using them for some kind of server side tech then you’re probably in the clear, but if you are distributing any eBPF code you write to a consumer (think IoT) then you’ll have to think about it.
- UncleEntity 9y ago
  I'm just surprised they would impose that restriction in the kernel considering they have very little problem with closed-source binary blobs for drivers and whatnot.
  - hacknat 9y ago
    Firmware can be closed source, but I’m fairly certain you have to open source the drivers too.
    - monocasa 9y ago
      It's grey area. For instance, Nvidia's probably safe with their closed source driver. Since their driver was originally for Windows and simply ported to Linux mainly via an abstraction layer, it'd be pretty difficult to prove to a judge that they're 'derived from' the Linux codebase.
      - bonzini 9y ago
        It's not "being derived from", it's "being a derivative of", which in turn has a legal meaning that need not exactly coincide with the usual English meaning. That said, lawyers have certainly given their approval to the way Nvidia packages their driver, so it should be fine or at least very very hard to challenge.
  - icebraining 9y ago
    Apparently you can now load non-GPL licensed eBPF programs, but they can't then access certain functions marked as "GPL only". This matches the behavior for kernel modules.
    - hacknat 9y ago
      Interesting. @icebraining, do you know where this list exists?
      - drzaeus77 9y ago
        The helpers are in http://elixir.free-electrons.com/linux/v4.15-rc3/source/kernel/bpf/helpers.c http://elixir.free-electrons.com/linux/v4.15-rc3/source/kern.... See the field gpl_only. For the list of which helpers are available in which hooks, the code needs to be read, to find things like: http://elixir.free-electrons.com/linux/v4.15-rc3/source/net/core/filter.c#L3357 http://elixir.free-electrons.com/linux/v4.15-rc3/source/net/.... Unfortunately, I don't believe the high level list of which hooks have gpl helpers is published, so reading the code is the best method currently.
        qeole 9y ago
        This list is under progress. Didn't think about adding licensing information for the helpers, but that's an excellent idea!
    - drzaeus77 9y ago
      The first BPF programs (original tcpdump use case) were always proprietary-compatible. If you think about it, there is nothing linux-specific about networking, and any code the user writes to tweak the data that is traversing their machine should be theirs to write, and doesn't taint the kernel. The same can be said for iptables/nft rules (you don't have to GPL your firewall configuration). Therefore, the BPF hooks that deal with packets (XDP, tc, socket) are not GPL-restricted and will remain so in the future. Where GPL comes in is when you use BPF to introspect the kernel. It is quite possible to use BPF programs with the kprobe hook to extract data about how the kernel itself works, and the opinion of the kernel developers on this is that such use cases are within the realm of GPL protection.
deleted 9y ago
[deleted]