eBPF

Summary

eBPF는 Linux 커널 안에서 제한된 프로그램을 안전하게 실행할 수 있게 해주는 기술이다. 커널 소스나 커널 모듈을 직접 수정하지 않고도 네트워크 패킷 처리, 시스템 호출 추적, 성능 분석, 보안 정책 적용 같은 기능을 구현할 수 있다.

여기서 중요한 점은 eBPF 자체가 방화벽이나 패킷 필터는 아니라는 것이다. eBPF는 프로그램을 커널 안에서 실행하는 기반이고, 실제 방화벽·모니터링·추적 로직은 eBPF 위에서 동작하는 개별 프로그램이 구현한다.

핵심은 이벤트가 발생하는 커널 지점에 프로그램을 연결하고, 필요한 데이터를 수집하거나 해당 지점의 동작에 영향을 주는 것이다.

Context

애플리케이션 로그만으로는 커널 내부에서 발생하는 지연이나 네트워크 문제를 확인하기 어렵다. 예를 들어 다음과 같은 질문에 답하려면 운영체제 수준의 정보가 필요하다.

• 어떤 프로세스가 특정 파일을 열고 있는가?
• TCP 연결이 어느 구간에서 지연되는가?
• 특정 시스템 호출이 얼마나 자주, 오래 실행되는가?
• 어떤 네트워크 패킷을 허용하거나 차단해야 하는가?

과거에는 커널 모듈을 작성하거나 별도의 계측 기능을 커널에 추가해야 하는 경우가 많았다. eBPF는 커널이 제공하는 검증 및 실행 환경을 이용해 이런 관측과 제어 기능을 더 작은 단위로 추가한다.

Problem and Questions

eBPF와 eBPF 프로그램은 무엇이 다르며, 프로그램은 커널의 어느 지점에서 실행되는가? 또한 Cilium 같은 도구는 eBPF와 어떤 관계인가?

Explanation

eBPF vs. eBPF Programs

eBPF를 하나의 완성된 애플리케이션으로 생각하면 개념이 헷갈리기 쉽다. 둘의 역할을 나누면 다음과 같다.

예를 들어 출발지 IP가 차단 목록에 있으면 패킷을 버리는 코드를 네트워크 수신 경로에 연결하면 그 프로그램은 방화벽처럼 동작한다. 같은 eBPF 기반에서 프로세스 시작 이벤트에 연결해 실행 파일 이름을 기록하면 프로세스 모니터가 되고, 디스크 I/O 이벤트에 연결해 지연 시간을 계산하면 스토리지 관측 도구가 된다.

개념적으로는 KVM : 가상 머신 = eBPF : eBPF 프로그램처럼 생각할 수 있다. KVM이 가상 머신 그 자체가 아니듯, eBPF도 방화벽이나 추적 도구 그 자체가 아니다.

Execution Flow

eBPF 프로그램의 기본 실행 흐름은 다음과 같다.

1. C, Rust 또는 bpftrace 같은 도구로 eBPF 프로그램을 작성한다.
2. 프로그램을 eBPF 바이트코드로 컴파일한다.
3. 사용자 공간의 로더가 bpf() 시스템 호출을 통해 프로그램을 커널에 적재한다.
4. 커널의 Verifier가 프로그램이 안전하게 종료되는지, 잘못된 메모리에 접근하지 않는지 등을 검사한다.
5. 검증을 통과한 프로그램은 인터프리터 또는 JIT 컴파일된 네이티브 코드로 실행된다.
6. 프로그램을 Tracepoint, Kprobe, XDP, TC, Cgroup 등의 이벤트 지점에 연결한다.
7. 이벤트가 발생할 때마다 eBPF 프로그램이 실행된다.

Verifier가 모든 위험을 제거한다는 의미는 아니지만, 임의의 커널 코드를 실행하는 커널 모듈과 비교하면 실행 가능한 동작과 메모리 접근이 강하게 제한된다.

Is eBPF Only for Networking?

eBPF는 NIC와 Linux 커널 사이의 패킷만 읽는 기술이 아니다. 네트워크 경로는 여러 연결 지점 중 하나일 뿐이며, 커널 내부의 다양한 서브시스템과 사용자 공간 함수에도 프로그램을 연결할 수 있다.

Linux 커널
├── 네트워크 스택  ← XDP, TC, Socket
├── 시스템 호출    ← Tracepoint, Kprobe
├── 스케줄러       ← Tracepoint
├── 파일 시스템    ← Kprobe, LSM
├── 보안            ← LSM, Cgroup
└── 디스크 I/O      ← Tracepoint, Kprobe

사용자 공간 프로세스 ← Uprobe

즉, 커널은 특정 이벤트가 발생했을 때 그 지점에 연결된 eBPF 프로그램을 실행한다. 프로그램이 실행되는 시점과 접근할 수 있는 데이터는 연결한 Hook과 프로그램 타입에 따라 달라진다.

Hooks: Program Attachment Points

Hook은 eBPF 프로그램이 실행되는 지점이다. 목적에 따라 연결 지점이 달라진다.

일반적으로 관측 목적이라면 Tracepoint를 우선 고려한다. Kprobe는 더 많은 커널 내부 함수에 접근할 수 있지만 커널 구현 변경의 영향을 받을 수 있다.

Why Run in the Kernel?

사용자 공간 프로그램이 모든 이벤트를 처리한다면 커널에서 데이터를 복사해 전달하고, 사용자 공간에서 판단한 뒤 다시 커널 동작에 반영하는 과정이 필요할 수 있다. 패킷처럼 매우 자주 발생하는 이벤트에서는 이런 경계 이동과 데이터 복사가 큰 비용이 된다.

사용자 공간에서 처리
이벤트 → 커널 → 데이터 전달 → 사용자 프로그램 → 결과 반영 → 커널

eBPF로 커널에서 처리
이벤트 → 연결된 eBPF 프로그램 실행 → 다음 동작

eBPF는 필요한 로직을 이벤트가 발생하는 지점 가까이에서 실행한다. 따라서 모든 이벤트를 사용자 공간으로 보내지 않고 필터링, 집계, 허용 또는 차단 같은 결정을 먼저 수행할 수 있다. 필요할 때만 결과를 Map이나 Ring Buffer를 통해 사용자 공간으로 전달한다.

Maps: State and Data Sharing

eBPF 프로그램은 실행 시간이 짧고 상태 저장에도 제약이 있다. 지속해서 사용할 데이터나 사용자 공간과 공유할 데이터는 eBPF Map에 저장한다.

Map은 키-값 저장소이며 Hash, Array, LRU Hash, Ring Buffer 등 여러 형태가 있다. 대표적인 사용 방식은 다음과 같다.

• 시스템 호출별 실행 횟수 집계
• 프로세스 ID별 네트워크 사용량 저장
• 허용하거나 차단할 IP 목록 전달
• 커널에서 수집한 이벤트를 사용자 공간으로 전송

즉, eBPF 프로그램은 이벤트를 처리하고 Map은 상태와 결과를 보관한다. 사용자 공간 프로그램은 Map을 읽거나 갱신해 eBPF 프로그램과 데이터를 주고받는다.

A Simple Observability Example

bpftrace를 사용하면 짧은 스크립트로 eBPF 기반 추적을 시험할 수 있다. 다음 명령은 프로세스별 execve 시스템 호출 횟수를 집계한다.

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve { @[comm] = count(); }'

실행 중인 eBPF 프로그램과 Map은 bpftool로 확인할 수 있다.

sudo bpftool prog list
sudo bpftool map list

Main Use Cases

• Observability: 시스템 호출, 함수 실행 시간, 네트워크 지연, CPU 사용 분석
• Networking: XDP 기반 패킷 처리, 로드 밸런싱, Kubernetes 네트워크 정책
• Security: 프로세스 및 파일 접근 감시, 런타임 위협 탐지, 정책 적용
• Performance: 커널과 애플리케이션의 병목 구간 추적

eBPF-based Tools and Platforms

Cilium은 하나의 eBPF 프로그램이 아니다. 각 노드에서 동작하는 Cilium Agent가 Kubernetes의 상태와 정책을 받아 목적에 맞는 여러 eBPF 프로그램과 Map을 관리한다. 네트워크 정책 검사, 서비스 로드 밸런싱, 연결 추적, 트래픽 관측은 서로 다른 Hook과 프로그램이 협력해 만들어내는 상위 기능이다.

따라서 Cilium = eBPF 프로그램보다는 **Cilium = 여러 eBPF 프로그램을 구성하고 관리하는 네트워킹 플랫폼**이라고 이해하는 편이 정확하다. eBPF 자체는 완성된 관측 도구가 아니라 이런 도구와 플랫폼을 구현하는 커널 실행 기반에 가깝다.

Limitations

• Verifier가 분석할 수 있는 형태로 프로그램을 작성해야 한다.
• 커널 버전과 설정에 따라 사용할 수 있는 기능이 다를 수 있다.
• Kprobe처럼 커널 내부 구현에 의존하는 방식은 호환성에 주의해야 한다.
• 높은 빈도로 발생하는 이벤트에서 데이터를 과도하게 수집하면 성능 비용이 커질 수 있다.
• 프로그램 적재와 연결에는 일반적으로 적절한 Linux capability 또는 관리자 권한이 필요하다.

Key Takeaways

• eBPF는 방화벽이나 모니터링 도구 자체가 아니라, 커널 이벤트에 작은 프로그램을 연결하고 실행하는 기반이다.
• 실제 패킷 필터링, 추적, 보안 정책은 목적에 맞게 작성된 eBPF 프로그램이 수행한다.
• eBPF 프로그램은 네트워크뿐 아니라 시스템 호출, 스케줄러, 파일 시스템, 디스크 I/O 등 여러 지점에서 실행될 수 있다.
• Verifier는 프로그램을 적재하기 전에 종료 가능성과 메모리 접근 등을 검사한다.
• Hook은 실행 시점을 결정하고, Map은 커널과 사용자 공간 사이의 상태 및 데이터 공유를 담당한다.
• Cilium은 하나의 eBPF 프로그램이 아니라 여러 프로그램과 Map을 관리해 네트워킹 기능을 구현하는 플랫폼이다.
• 실제 적용에서는 커널 호환성, 권한, 수집 비용을 함께 고려해야 한다.

References

• Linux Kernel BPF Documentation
• Cilium BPF Architecture
• Cilium Component Overview