License: GPL v3

🍯 Honey Potion - Writing eBPF with Elixir 🍯

logo

Description

Honey Potion is a framework that brings the powerful eBPF technology into Elixir. Users can write Elixir code that will be transformed into eBPF bytecodes. Many high-level features of Elixir are available and more will be added soon. In this alpha version, the framework translates the code to a subset of C that uses libbpf's features. Then it's possible to use clang to obtain the bytecodes and load it into the Kernel.

Installation

The package can be installed by adding honey to your list of dependencies in mix.exs:

def deps do
  [
    {:honey, git: "https://github.com/lac-dcc/honey-potion/"}
  ]
end

Usage

When you use Honey in your module, it'll be translated to C the next time you compile the project. For example:

defmodule Minimal do
  use Honey, license: "Dual BSD/GPL"

  # ...
end

Will generate Minimal.bpf.c in the same folder as the module.

Notice the license option: as eBPF demands, we need to specify a license to our program. Currently, Honey accepts one more option besides the license. The option clang_formater can take the path of the clang-formater executable, and it'll use it to beautify the C file generated.

Main function

A module that uses Honey must define a function main/1 that receives a ctx. The main function is the entry point of our eBPF program. For example:

defmodule Example.Minimal do
  use Honey, license: "Dual BSD/GPL"

  @sec "tracepoint/syscalls/sys_enter_kill"
  def main(ctx) do
    # ...
  end
end

Notice the @sec decorator: The main function must specify its program type, according to the available options in libbpf. The argument received, ctx, is a struct whose fields vary depending on the program type. In its Alpha version, only one type is allowed: tracepoint/syscalls/sys_enter_kill.

The main function must return an integer, otherwise an exception will be thrown at runtime (see Runtime Exceptions below).

Maps

Users can define maps using the macro defmap. For example, to create a map named my_map, you can:

defmap(:my_map,
     %{type: BPF_MAP_TYPE_ARRAY,
     max_entries: 10}
)

In the Alpha version, just the map type BPF_MAP_TYPE_ARRAY is available, but you only need to specify the number of entries and the map is ready to use.

Helper functions

eBPF and libbpf provides some helper functions, and so does Honey. In the Alpha version, there is a single module you can import:

import Honey.Bpf.Bpf_helpers

Referencing the usual #include <bpf/bpf_helpers>, this module allows you to call:

Recursive functions

It is possible to define recursive functions and call them from main/1. For example, let's define a function that recursively sums two natural numbers:

def sum(a, b) do
  if(b == 0) ->
     a
  else
    sum(a + 1, b - 1)
  end
end

To avoid infinite recursion and satisfy the eBPF verifier, we require you to inform a constant number that will be used to limit the maximum depth of recursion at runtime. This is done through the macro fuel. Its syntax is: fuel max_number, function_call(...)

Let's see an example inside main:

@sec "tracepoint/syscalls/sys_enter_kill"
def main(ctx) do
  x = 100
  y = fuel 10, sum(x, 5)
  bpf_printk(["The value of y is %d", y])
end

We provide a constant amount of 10 units fuel in the first call sum. Each time sum calls itself, it burns one unit of fuel. If, at some point, sum tries to calls itself again with no fuel remaining, a Runtime Exception will be thrown and the program will halt.

Runtime Exceptions

Exceptions are a natural part of dynamically-typed languages such as Elixir. To allow many of the high-level constructs of Elixir, we simulate the notion of Runtime Exceptions when translating programs to eBPF. In this Alpha version, when a Runtime Exception is thrown, the program will print the exception message to the debug pipe, and return with 0.

Current limitations & Contributing

This framework is still Alpha, and we have lots of features to add, improve and correct. Amongst the current known limitations are:

There are more, and we are actively working to improve it.

Contributions are very welcome! If you are interested in collaborating, let's stay in touch so our work doesn't overlap. Feedback and suggestions are also very much appreciated! You can file a Github issue or contact us at vinicpac@gmail.com.