Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add embedded clang/llvm for runtime compilation of eBPF programs #6978

Merged
merged 78 commits into from
Jan 21, 2021

Conversation

brycekahle
Copy link
Member

@brycekahle brycekahle commented Dec 11, 2020

What does this PR do?

Adds a statically-linked, embedded clang/llvm for runtime compilation of eBPF programs. If enabled, these programs are compiled on-demand. The output object file is cached, such that if any of the following changes, it will be re-compiled:

  1. Kernel version
  2. Source file hash

Each runtime-compiled source file is pre-processed during CI build to be a concatenation of the .c and all user (non-kernel) .h files. Also during CI build, a hash is computed for the pre-processed file, such that any modifications on the host would result in refusing to compile the program.

The pre-processed .c file is distributed separately from the system-probe binary, like our .o files, since it must be GPL-licensed to use certain kernel BPF helper functions.

Motivation

Planned features for networks and/or the system-probe require access to kernel structures that are too difficult to access with offset guessing. Runtime compilation allows us to compile on each host so it is targeted for the running kernel.

Additional Notes

  1. This PR does not address any kind of automatic kernel-header downloading/installation. It will attempt to automatically find compatible headers, but a path can be provided via a config option.
  2. The compiler currently does not support in-memory buffers or bundled files. If we decide to keep bundling (currently up for discussion), then that support will be added later.
  3. The arm64 system-probe build is currently failing, due to g++ being killed. I'm investigating why, but it was not happening before I rebased on master.
    1. This is because of a 3GB memory limit on builds. This limit is being revisited.

Describe your test plan

The kitchen tests currently pass across a wide range of kernels/distros, but the runtime compilations tests only ensure that the programs can be compiled. The CI tests are run another time with the runtime compiler enabled.

Further testing with system_probe_config.enable_runtime_compiler turned on would be useful.

`inv deps` did not like it when these files were missing and not generated yet
This figures out the correct path if deployed in a similar repo structure to how it was built. Otherwise, it assumes you are running from the root directory.
Copy link
Contributor

@xornivore xornivore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm for container-integrations

@xornivore xornivore added need-change/helm-chart Add this label if your change require also a change in the datadog helm chart need-change/operator Add this label if you change request also a change in the datadog-operator labels Jan 4, 2021
// defaultProxyPort is the default port used for proxies.
// This mirrors the configuration for the infrastructure agent.
defaultProxyPort = 3128

// defaultSystemProbeBPFDir is the default path for eBPF programs
defaultSystemProbeBPFDir = "/opt/datadog-agent/embedded/share/system-probe/ebpf"

// defaultRuntimeCompilerOutputDir is the default path for output from the system-probe runtime compiler
defaultRuntimeCompilerOutputDir = "/var/tmp/datadog-agent/system-probe/build"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is also defined separately as a default in pkg/ebpf/config.go. Might be worth cleaning up so its defined once. Fine if this is done in a separate follow-up PR .

Copy link
Member

@sunhay sunhay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM on the Processes-side for configuration. I haven't dug into the actual runtime compilation pieces given its been thoroughly reviewed and approved.

@brycekahle brycekahle force-pushed the bryce.kahle/runtime-compilation branch from 4442771 to 4cbf304 Compare January 21, 2021 16:46
@brycekahle brycekahle merged commit 28e19ac into master Jan 21, 2021
@brycekahle brycekahle deleted the bryce.kahle/runtime-compilation branch January 21, 2021 18:38
brycekahle added a commit to DataDog/helm-charts that referenced this pull request Jan 21, 2021
brycekahle added a commit to DataDog/helm-charts that referenced this pull request Jan 21, 2021
brycekahle added a commit to DataDog/helm-charts that referenced this pull request Jan 22, 2021
brycekahle added a commit to DataDog/helm-charts that referenced this pull request Jan 22, 2021
brycekahle added a commit to DataDog/helm-charts that referenced this pull request Mar 2, 2021
sergei-deliveroo pushed a commit to deliveroo/datadog-agent that referenced this pull request Mar 24, 2021
brycekahle added a commit to DataDog/helm-charts that referenced this pull request Apr 20, 2021
brycekahle added a commit to DataDog/helm-charts that referenced this pull request Apr 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need-change/helm-chart Add this label if your change require also a change in the datadog helm chart need-change/operator Add this label if you change request also a change in the datadog-operator team/networks
Projects
None yet
Development

Successfully merging this pull request may close these issues.