ebpf

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

We should provide multi-architecture Docker images of skywalking-eyes, just like other SkyWalking sub-projects.

Use case

No response

Related issues

No response

Are you willing to submit a PR?

• [

Seems we have some language features not fully documented (like bitshift operators in #1322).

Would be good to go through language grammar and make sure everything is in the reference guide.

Is your feature request related to a problem? Please describe.
I want to install Pixie from an Infra as Code pipeline or from a git repo that I am syncing config from to n clusters.

Describe the solution you'd like
It would be great if this install style were documented somewhere.

Currently we have just one type of docs which are "reference" documentation. We should add a "how-to/tutorials" section with goal-driven content. We can start by drawing already available content:

https://blog.aquasec.com/kubernetes-runtime-security-ebpf
https://blog.aquasec.com/tracee-runtime-malware-alerts-aqua-postee
https://blog.aquasec.com/runtime-security-tracee-rules
https://github.co

At the moment of writing this issue, kubectl trace only supports X86-64 as target architecture.

The tool should be able to schedule bpftrace programs against all the architectures supported by bpftrace, that are X86-64 and arm64 (aarch64) see the Cmake definition.

To achieve that we n

Our eBPF code makes some arch-specific assumptions about the layout of struct pt_regs. We need to refactor this to use BPF CO-RE macros to make multi-arch support work properly for our kprobes.

It appears that the RedBPF toolchain imposes currently undocumented restrictions on map value types that go beyond those expressed by the generic constraints:

• All variants of an enum must have the same size in memory.
• Struct fields are (mostly?) required to be aligned to multiples of 32 bits, though sometimes 64-bit alignment is required, and some structs don't work at all despite their fi

This should work something like this:

From xtask:

cargo xtask integration-test --libbpf-dir ~/dev/libbpf -- -t tests::load::unload

On the integration-test side it's a flag -t that can be repeated multiple times to enable more tests...

integration-test -t tests::load::unload

Minikube start

General Information

• Environment (minikube)
• Kernel version (Linux eswar-LEGION 5.13.0-52-generic #59~20.04.1-Ubuntu SMP Thu Jun 16 21:21:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux)

To Reproduce

1. Goto contributions minikube.
2. Install minikube and virtualbox using scripts mentioned under contributions/minikube dir.
3. Then run minikube with start_minik

Bug Description

【question】

   pilot-agent-69571   [006] d... 270197.943731: bpf_trace_printk: [debug] get current pod ip error
     pilot-agent-69571   [006] d... 270197.943738: bpf_trace_printk: [debug] call from sidecar container: cookie: 780438927, ip: 0xa9fcf8ac, port: 8080
     pilot-agent-91591   [030] d... 270198.324635: bpf_trace_printk: [debug] get current pod ip error
     

Can we get some performance comparison between polycube and using standard linux facilities (NAT, iptables, etc.)?

CPU usage, PPS, latencies, etc.

Since the kernel's libbpf seems to handle .text ELF sections gracefully, we should probably do that too.