eBPF

  • eBPF(extended Berkeley Packet Filter): Linux Kernel 내부에서 안전하게 실행되는 작은 프로그램을 이용해서 커널의 동작을 확장하는 기술
  • eBPF 는 커널 소스코드를 직접 수정하거나 Kernel Module 을 새로 로드하지 않고도 Kernel 내부의 특정 지점에 프로그램을 붙여서 실행할 수 있게 해준다.
    • 예를 들어 시스템 콜, 네트워크 패킷 처리 지점, 파일 접근 지점, 프로세스 실행 지점, 커널 함수 호출 지점 등에 eBPF Program 을 연결하면 해당 이벤트가 발생했을 때 eBPF Program 이 실행된다.
  • eBPF 는 단순히 패킷 필터링만을 위한 기술이 아니라, 현대 Linux 환경에서 Observability, Networking, Security, Tracing 등에 사용되는 커널 확장 기술이라고 볼 수 있다.

BPF 와 eBPF

초기 BPF 는 Berkeley Packet Filter 의 약자로, 네트워크 패킷을 필터링하기 위한 기술이었다.

예를 들어 tcpdump 나 Wireshark 에서 특정 조건의 패킷만 캡처할 때 BPF 필터가 사용된다.

tcpdump tcp port 80

위와 같은 필터는 모든 패킷을 User Space 로 가져온 뒤 필터링하는 것이 아니라, Kernel Space 에서 먼저 조건에 맞는 패킷만 걸러낼 수 있게 해준다.

즉, 기존 BPF 의 핵심 목적은 네트워크 패킷 필터링이었다.

하지만 eBPF 는 기존 BPF 를 확장해서 네트워크뿐만 아니라 커널 내부의 다양한 지점에서 프로그램을 실행할 수 있도록 만든 구조이다.

그래서 eBPF 는 단순한 Packet Filter 라기보다는 Kernel 내부에서 안전하게 실행되는 Event-driven Program 실행 환경에 가깝다.

Kernel Space 와 User Space

eBPF 를 이해할 때 가장 중요한 개념 중 하나는 Kernel Space 와 User Space 이다.

  • Kernel Space: 운영체제 커널이 실행되는 영역
  • User Space: 일반 애플리케이션이 실행되는 영역

일반적인 프로그램은 User Space 에서 실행된다.

예를 들어 웹 서버, 쉘, 브라우저, 일반적인 C 프로그램은 대부분 User Space 에서 실행된다.

반면 Kernel Space 는 시스템 콜 처리, 파일 시스템, 네트워크 스택, 프로세스 스케줄링, 메모리 관리 같은 핵심 기능을 담당한다.

User Space 프로그램이 파일을 열거나 네트워크 통신을 하거나 프로세스를 생성하려면 결국 Kernel 의 기능을 사용해야 한다.

예를 들어 다음과 같은 코드가 있다고 하면

open("/etc/passwd", 0);

이 코드는 User Space 에서 실행되지만, 실제 파일 접근은 Kernel Space 에서 처리된다.

eBPF 는 바로 이 Kernel Space 의 특정 실행 지점에 작은 프로그램을 연결해서, 이벤트가 발생했을 때 Kernel 내부에서 직접 동작할 수 있게 해준다.

eBPF Program

eBPF Program 은 Kernel 내부에서 실행되는 작은 프로그램이다.

보통 C 언어로 작성한 뒤 LLVM/Clang 을 이용해서 eBPF Bytecode 로 컴파일한다.

SEC("tracepoint/syscalls/sys_enter_execve")
int handle_execve(void *ctx) {
    return 0;
}

위 코드는 execve 시스템 콜 진입 지점에 연결될 수 있는 eBPF Program 의 예시이다.

이 프로그램은 사용자가 새로운 프로그램을 실행할 때 Kernel 내부에서 실행될 수 있다.

eBPF Program 은 일반적인 User Space 프로그램처럼 아무 동작이나 할 수 있는 것이 아니다.

Kernel 내부에서 실행되기 때문에 안정성과 보안이 매우 중요하다.

그래서 eBPF Program 은 Kernel 에 로드되기 전에 Verifier 의 검사를 통과해야 한다.

eBPF 의 실행 흐름

eBPF Program 은 보통 다음과 같은 흐름으로 실행된다.

  1. 개발자가 eBPF Program 을 작성한다.
  2. Clang/LLVM 으로 eBPF Bytecode 로 컴파일한다.
  3. User Space Loader 가 bpf() syscall 을 통해 eBPF Program 을 Kernel 로 로드한다.
  4. Kernel Verifier 가 eBPF Program 이 안전한지 검사한다.
  5. 검증을 통과하면 eBPF Program 이 Kernel 에 로드된다.
  6. eBPF Program 을 특정 Hook Point 에 Attach 한다.
  7. 해당 Kernel Event 가 발생하면 eBPF Program 이 실행된다.
  8. eBPF Program 은 Map, Ring Buffer, Helper Function 등을 통해 데이터를 저장하거나 User Space 로 전달한다.

즉, eBPF 는 단순히 코드를 Kernel 에 넣는 것이 아니라, Verifier 검증, Program Load, Attach, Event Trigger, Data Export 의 흐름으로 동작한다.

Hook Point

Hook Point 는 eBPF Program 이 연결되는 Kernel 내부의 실행 지점이다.

eBPF Program 은 아무 곳에서나 실행되는 것이 아니라, 특정 이벤트나 특정 Kernel 경로에 연결되어 실행된다.

대표적인 Hook Point 는 다음과 같다.

Tracing
    - kprobe
    - kretprobe
    - tracepoint
    - fentry
    - fexit

Networking
    - XDP
    - TC
    - socket filter
    - cgroup skb
    - cgroup sock

Security
    - LSM hook

User Space Tracing
    - uprobe
    - uretprobe

예를 들어 kprobe 는 커널 함수가 호출될 때 eBPF Program 을 실행할 수 있게 해준다.

tracepoint 는 커널에서 미리 정의된 추적 지점에 eBPF Program 을 연결할 수 있게 해준다.

XDP 는 네트워크 패킷이 커널 네트워크 스택으로 올라오기 전, NIC Driver 에 가까운 지점에서 패킷을 처리할 수 있게 해준다.

LSM hook 은 파일 접근, 프로세스 실행, 권한 검사 같은 보안 판단 지점에 eBPF Program 을 연결할 수 있게 해준다.

Program Type

eBPF Program 은 연결되는 위치와 목적에 따라 Program Type 이 나뉜다.

Program Type 은 해당 eBPF Program 이 어떤 Kernel Context 에서 실행되는지, 어떤 Helper Function 을 사용할 수 있는지, 어떤 반환값을 가져야 하는지를 결정한다.

대표적인 Program Type 은 다음과 같다.

BPF_PROG_TYPE_KPROBE
BPF_PROG_TYPE_TRACEPOINT
BPF_PROG_TYPE_XDP
BPF_PROG_TYPE_SCHED_CLS
BPF_PROG_TYPE_SOCKET_FILTER
BPF_PROG_TYPE_CGROUP_SKB
BPF_PROG_TYPE_CGROUP_SOCK_ADDR
BPF_PROG_TYPE_LSM
BPF_PROG_TYPE_PERF_EVENT

예를 들어 XDP Program 은 네트워크 패킷을 빠르게 처리하기 위한 Program Type 이다.

XDP Program 은 패킷을 그대로 통과시킬지, 드롭할지, 다른 인터페이스로 리다이렉트할지 등을 결정할 수 있다.

XDP_PASS
XDP_DROP
XDP_REDIRECT
XDP_TX

반면 LSM Program 은 보안 Hook 에 연결되어 특정 행위를 허용하거나 차단하는 데 사용할 수 있다.

예를 들어 파일 열기, 프로세스 실행, 소켓 연결 같은 지점에서 정책 기반으로 접근을 제어할 수 있다.

즉, eBPF Program Type 은 eBPF Program 의 실행 위치와 권한 범위를 결정하는 중요한 요소이다.

Verifier

Verifier 는 eBPF Program 이 Kernel 에 로드되기 전에 안전한지 검사하는 Kernel 내부 검증기이다.

eBPF Program 은 Kernel Space 에서 실행되기 때문에 잘못된 메모리 접근이나 무한 루프, 잘못된 포인터 사용이 발생하면 Kernel 전체의 안정성에 영향을 줄 수 있다.

그래서 Kernel 은 eBPF Program 을 바로 실행하지 않고 Verifier 를 통해 먼저 검증한다.

Verifier 는 대략 다음과 같은 내용을 검사한다.

  • 잘못된 메모리 접근이 없는지
  • 초기화되지 않은 값이 사용되지 않는지
  • 포인터가 안전하게 사용되는지
  • Program Type 에서 허용되지 않은 Helper Function 을 호출하지 않는지
  • Stack 범위를 벗어나지 않는지
  • 프로그램이 종료 가능한지
  • Context 접근이 올바른지

예를 들어 eBPF Program 에서 임의의 Kernel 주소를 직접 읽으려고 하면 Verifier 에 의해 거부될 수 있다.

int *ptr = (int *)0xffffffff81000000;
return *ptr;

eBPF Program 은 Kernel 내부에서 실행되지만, 일반적인 Kernel Module 처럼 무제한으로 Kernel 메모리에 접근할 수 있는 것이 아니다.

Verifier 가 eBPF Program 의 레지스터 상태, 스택 상태, 분기 흐름 등을 추적해서 안전한 프로그램인지 검사한다.

이 과정이 있기 때문에 eBPF 는 Kernel 내부에서 실행되면서도 비교적 안전한 실행 모델을 제공할 수 있다.

JIT Compile

eBPF Program 은 처음에는 eBPF Bytecode 형태로 Kernel 에 로드된다.

그 후 Kernel 은 해당 Bytecode 를 해석해서 실행하거나, JIT Compile 을 통해 Native Machine Code 로 변환해서 실행할 수 있다.

JIT 는 Just-In-Time Compilation 의 약자이다.

eBPF JIT Compile 이 활성화되어 있으면 eBPF Bytecode 는 실행 시점에 실제 CPU 아키텍처에 맞는 기계어로 변환된다.

예를 들어 x86-64 환경에서는 eBPF Bytecode 가 x86-64 Machine Code 로 변환될 수 있다.

이렇게 하면 매번 Bytecode 를 해석하는 방식보다 더 빠르게 실행할 수 있다.

즉, eBPF 는 Kernel 내부에서 실행되지만, Verifier 로 안전성을 확보하고 JIT Compile 로 성능을 확보하는 구조라고 볼 수 있다.

eBPF Map

eBPF Map 은 eBPF Program 과 User Space 프로그램이 데이터를 공유하기 위한 Kernel 내부 자료구조이다.

eBPF Program 은 일반적인 프로그램처럼 전역 변수를 자유롭게 사용할 수 없기 때문에, 상태 저장이나 데이터 공유를 위해 Map 을 사용한다.

Map 은 Key-Value 형태의 저장소라고 볼 수 있다.

예를 들어 특정 PID 의 이벤트 수를 저장하거나, 특정 IP 의 패킷 수를 저장하거나, User Space 에서 전달한 정책 정보를 Kernel 에서 조회할 때 Map 을 사용할 수 있다.

대표적인 Map Type 은 다음과 같다.

BPF_MAP_TYPE_HASH
BPF_MAP_TYPE_ARRAY
BPF_MAP_TYPE_PERCPU_HASH
BPF_MAP_TYPE_PERCPU_ARRAY
BPF_MAP_TYPE_LRU_HASH
BPF_MAP_TYPE_RINGBUF
BPF_MAP_TYPE_PERF_EVENT_ARRAY
BPF_MAP_TYPE_PROG_ARRAY
BPF_MAP_TYPE_LPM_TRIE

예를 들어 Hash Map 은 특정 Key 에 대한 Value 를 저장할 때 사용할 수 있다.

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 1024);
    __type(key, __u32);
    __type(value, __u64);
} counter SEC(".maps");

위 Map 은 __u32 타입의 Key 와 __u64 타입의 Value 를 가지는 Hash Map 이다.

eBPF Program 에서는 Helper Function 을 통해 Map 에 접근한다.

__u64 *value;
__u32 key = 1;

value = bpf_map_lookup_elem(&counter, &key);

bpf_map_lookup_elem 은 Map 에서 특정 Key 에 해당하는 Value 를 조회하는 Helper Function 이다.

즉, eBPF Map 은 eBPF Program 의 상태 저장소이자 User Space 와 Kernel Space 사이의 통신 통로이다.

Helper Function

Helper Function 은 eBPF Program 이 Kernel 기능을 안전하게 사용할 수 있도록 Kernel 이 제공하는 함수이다.

eBPF Program 은 일반적인 C 라이브러리 함수를 마음대로 호출할 수 없다.

예를 들어 eBPF Program 내부에서 printf, malloc, open 같은 일반적인 함수를 사용할 수 없다.

대신 Kernel 이 허용한 Helper Function 을 통해 제한된 기능을 수행한다.

대표적인 Helper Function 은 다음과 같다.

bpf_map_lookup_elem
bpf_map_update_elem
bpf_map_delete_elem
bpf_ktime_get_ns
bpf_get_current_pid_tgid
bpf_get_current_comm
bpf_probe_read_kernel
bpf_probe_read_user
bpf_ringbuf_output
bpf_perf_event_output
bpf_tail_call

예를 들어 현재 프로세스의 PID 를 가져오려면 bpf_get_current_pid_tgid Helper Function 을 사용할 수 있다.

__u64 pid_tgid = bpf_get_current_pid_tgid();

현재 프로세스 이름을 가져오려면 bpf_get_current_comm 을 사용할 수 있다.

char comm[16];
bpf_get_current_comm(&comm, sizeof(comm));

Helper Function 은 Program Type 에 따라 사용할 수 있는 종류가 다르다.

예를 들어 XDP Program 에서 사용할 수 있는 Helper Function 과 LSM Program 에서 사용할 수 있는 Helper Function 이 다를 수 있다.

즉, Helper Function 은 eBPF Program 이 Kernel 과 상호작용하기 위한 제한된 API 라고 볼 수 있다.

Loader

Loader 는 User Space 에서 eBPF Program 을 Kernel 로 로드하고 Attach 하는 프로그램이다.

eBPF Program 은 C 파일만 작성한다고 자동으로 Kernel 에 올라가는 것이 아니다.

User Space 에서 Loader 가 eBPF Object File 을 읽고, Map 을 생성하고, Program 을 로드하고, Hook Point 에 Attach 해야 한다.

대표적으로 libbpf, BCC, bpftrace 같은 도구나 라이브러리가 Loader 역할을 수행할 수 있다.

eBPF C Program
        ↓
Clang/LLVM Compile
        ↓
eBPF Object File
        ↓
User Space Loader
        ↓
bpf() syscall
        ↓
Kernel Verifier
        ↓
Attach to Hook Point

libbpf 는 eBPF Program 을 로드하고 관리하기 위한 C 라이브러리이다.

최근에는 BTF 와 CO-RE 를 함께 사용해서 커널 버전 차이에 더 유연하게 대응하는 방식이 많이 사용된다.

BTF 와 CO-RE

BTF 는 BPF Type Format 의 약자이다.

BTF 는 Kernel 내부 구조체와 타입 정보를 eBPF Program 이 활용할 수 있도록 제공하는 메타데이터 형식이다.

eBPF Program 은 Kernel 내부 구조체를 참조해야 하는 경우가 많다.

하지만 Kernel 구조체는 커널 버전이나 빌드 설정에 따라 필드 위치가 달라질 수 있다.

예를 들어 어떤 Kernel 버전에서는 구조체의 특정 필드가 앞쪽에 있고, 다른 Kernel 버전에서는 뒤쪽에 있을 수 있다.

이때 필드 오프셋을 하드코딩하면 커널 버전이 바뀌었을 때 eBPF Program 이 깨질 수 있다.

CO-RE 는 Compile Once - Run Everywhere 의 약자이다.

CO-RE 는 BTF 정보를 이용해서 eBPF Program 이 여러 Kernel 버전에서 비교적 유연하게 실행될 수 있도록 하는 방식이다.

즉, BTF 는 Kernel Type 정보를 제공하고, CO-RE 는 그 정보를 기반으로 커널 버전 차이를 보정해서 eBPF Program 의 이식성을 높여준다.

Ring Buffer 와 Perf Buffer

eBPF Program 은 Kernel 내부에서 발생한 이벤트를 User Space 로 전달해야 하는 경우가 많다.

예를 들어 어떤 프로세스가 실행되었는지, 어떤 파일이 열렸는지, 어떤 네트워크 연결이 발생했는지 User Space 에서 확인하려면 Kernel 에서 User Space 로 이벤트를 전달해야 한다.

이때 사용할 수 있는 대표적인 방식이 Ring Buffer 와 Perf Buffer 이다.

Ring Buffer 는 Kernel 에서 이벤트 데이터를 기록하고, User Space 프로그램이 이를 읽어가는 구조이다.

struct event {
    __u32 pid;
    char comm[16];
};

eBPF Program 은 이벤트 구조체를 만들고 Ring Buffer 로 전송할 수 있다.

User Space Loader 는 Ring Buffer 를 Polling 하면서 이벤트를 읽는다.

즉, Ring Buffer 는 eBPF 기반 모니터링 도구에서 Kernel Event 를 User Space 로 전달하기 위한 주요 통신 방식 중 하나이다.

XDP

XDP 는 eXpress Data Path 의 약자이다.

XDP 는 네트워크 패킷을 매우 이른 시점에 처리하기 위한 eBPF Hook 이다.

일반적으로 네트워크 패킷은 NIC 에서 들어온 뒤 Kernel Network Stack 을 거쳐 Socket 으로 전달된다.

하지만 XDP 는 패킷이 Kernel Network Stack 으로 올라가기 전에 eBPF Program 을 실행할 수 있다.

그래서 XDP 는 매우 빠른 패킷 필터링이나 DDoS 방어, 로드밸런싱, 패킷 리다이렉션 등에 사용될 수 있다.

XDP Program 은 패킷에 대해 다음과 같은 결정을 내릴 수 있다.

  • XDP_PASS: 패킷을 통과시킨다.
  • XDP_DROP: 패킷을 버린다.
  • XDP_REDIRECT: 패킷을 다른 인터페이스나 CPU 로 리다이렉트한다.
  • XDP_TX: 패킷을 수신한 인터페이스로 다시 전송한다.

예를 들어 특정 조건의 패킷을 Kernel Network Stack 으로 올리지 않고 바로 Drop 하면 불필요한 비용을 줄일 수 있다.

이 때문에 XDP 는 고성능 네트워크 처리에서 자주 언급된다.

TC eBPF

TC 는 Traffic Control 의 약자이다.

TC eBPF 는 Linux Traffic Control 계층에 eBPF Program 을 붙여서 패킷을 처리하는 방식이다.

XDP 는 매우 이른 단계에서 패킷을 처리하고, TC 는 Kernel Network Stack 에 조금 더 들어온 뒤의 패킷 처리 지점에서 동작한다.

TC eBPF 는 Ingress 와 Egress 방향 모두에서 사용할 수 있다.

  • Ingress: 들어오는 패킷
  • Egress: 나가는 패킷

TC eBPF 는 패킷 필터링, 트래픽 제어, 패킷 수정, 네트워크 정책 적용 등에 사용할 수 있다.

XDP 가 더 낮은 레벨에서 빠른 처리를 담당한다면, TC eBPF 는 조금 더 풍부한 Kernel Context 를 활용해서 패킷을 제어할 수 있다.

Tracing

eBPF 는 커널과 애플리케이션의 동작을 추적하는 데 자주 사용된다.

Tracing 은 시스템 내부에서 어떤 함수가 호출되었는지, 어떤 시스템 콜이 발생했는지, 어떤 지연이 발생했는지 관찰하는 기술이다.

eBPF Tracing 에서 자주 사용되는 Hook 은 다음과 같다.

kprobe
kretprobe
tracepoint
fentry
fexit
uprobe
uretprobe

kprobe 는 커널 함수 진입 지점에 eBPF Program 을 붙이는 방식이다.

kretprobe 는 커널 함수 반환 지점에 eBPF Program 을 붙이는 방식이다.

tracepoint 는 커널에서 안정적으로 제공하는 추적 지점에 붙는 방식이다.

uprobe 는 User Space 프로그램의 함수에 eBPF Program 을 붙이는 방식이다.

예를 들어 특정 프로그램의 malloc 호출을 추적하거나, 특정 라이브러리 함수의 호출 횟수를 확인하는 것도 uprobe 를 통해 가능하다.

즉, eBPF 는 Kernel Space 뿐만 아니라 User Space 프로그램의 실행 흐름을 관찰하는 데도 사용될 수 있다.

eBPF LSM

eBPF LSM 은 Linux Security Module Hook 에 eBPF Program 을 연결하는 방식이다.

LSM 은 Linux Kernel 의 보안 결정을 처리하기 위한 프레임워크이다.

파일 접근, 프로세스 실행, 권한 검사, 소켓 연결 같은 보안 관련 지점에서 LSM Hook 이 호출된다.

eBPF LSM 을 사용하면 이러한 보안 판단 지점에 eBPF Program 을 붙여서 정책 기반으로 행위를 허용하거나 차단할 수 있다.

예를 들어 특정 프로세스가 /etc/shadow 를 열려고 할 때 이를 차단하거나, 특정 포트로 연결하려는 행위를 거부할 수 있다.

SEC("lsm/file_open")
int BPF_PROG(check_file_open, struct file *file) {
    return 0;
}

위와 같은 형태로 LSM Hook 에 eBPF Program 을 연결할 수 있다.

LSM Program 은 단순히 관찰만 하는 것이 아니라 반환값을 통해 특정 행위를 거부할 수 있다는 점에서 보안 정책 집행에 사용할 수 있다.

eBPF 의 활용 분야

eBPF 는 다양한 분야에서 사용된다.

대표적인 활용 분야는 다음과 같다.

  • Observability
  • Networking
  • Security
  • Performance Profiling
  • Runtime Enforcement
  • Container Monitoring
  • Kubernetes Networking
  • DDoS Mitigation
  • System Call Tracing
  • File Access Monitoring

Observability 분야에서는 시스템 콜, 네트워크 연결, 파일 접근, CPU 사용, 함수 호출 지연 등을 추적하는 데 사용된다.

Networking 분야에서는 XDP, TC 등을 이용해서 패킷 필터링, 로드밸런싱, 네트워크 정책 적용, 패킷 리다이렉션 등을 수행할 수 있다.

Security 분야에서는 eBPF LSM, kprobe, tracepoint 등을 이용해서 의심 행위를 탐지하거나 차단할 수 있다.

Container 환경에서는 프로세스, 네트워크, 파일 접근을 추적해서 컨테이너 단위의 보안 모니터링을 수행할 수 있다.

eBPF 와 Kernel Module 의 차이

eBPF 와 Kernel Module 은 둘 다 Kernel 기능을 확장할 수 있다는 공통점이 있다.

하지만 두 방식은 안정성과 개발 방식에서 차이가 있다.

Kernel Module 은 Kernel 에 직접 로드되는 코드이다.

Kernel Module 은 강력하지만, 잘못 작성하면 Kernel Panic 을 발생시키거나 시스템 전체를 불안정하게 만들 수 있다.

반면 eBPF Program 은 Kernel 에 로드되기 전에 Verifier 의 검사를 받는다.

그래서 잘못된 메모리 접근, 무한 루프, 잘못된 포인터 사용 등이 제한된다.

또한 eBPF 는 Hook Point 와 Program Type 에 따라 실행 위치와 기능이 제한된다.

즉, Kernel Module 은 더 자유롭고 강력하지만 위험성이 크고, eBPF 는 더 제한적이지만 안전하게 Kernel 기능을 확장할 수 있는 방식이라고 볼 수 있다.

eBPF 의 제한 사항

eBPF 는 모든 것을 할 수 있는 기술은 아니다.

eBPF Program 은 Kernel 내부에서 실행되기 때문에 여러 제한이 존재한다.

대표적인 제한 사항은 다음과 같다.

  • Verifier 검증을 통과해야 한다.
  • Program Type 에 따라 사용할 수 있는 Helper Function 이 제한된다.
  • 임의의 Kernel 메모리에 자유롭게 접근할 수 없다.
  • 일반적인 C 라이브러리 함수를 사용할 수 없다.
  • Stack 크기가 제한된다.
  • 복잡한 반복문이나 분기 구조는 Verifier 에 의해 거부될 수 있다.
  • Kernel Version 에 따라 지원되는 기능이 다를 수 있다.

이러한 제한은 불편해 보일 수 있지만, Kernel 안정성을 유지하기 위해 필요한 제약이다.

eBPF 는 Kernel 내부에서 실행되기 때문에 성능과 안전성 사이의 균형이 중요하다.

eBPF 중요한 이유

eBPF 가 중요한 이유는 Kernel 을 수정하지 않고도 Kernel 수준의 관찰과 제어가 가능하기 때문이다.

기존에는 Kernel 내부 동작을 관찰하거나 제어하기 위해 Kernel Module 을 작성하거나, 커널을 패치하거나, ptrace 같은 상대적으로 무거운 방식을 사용해야 했다.

하지만 eBPF 를 사용하면 Kernel 의 특정 지점에 작은 프로그램을 동적으로 연결해서 필요한 데이터를 수집하거나 정책을 적용할 수 있다.

예를 들어 어떤 프로세스가 어떤 파일을 열었는지, 어떤 IP 로 연결했는지, 어떤 시스템 콜을 호출했는지, 어떤 함수에서 지연이 발생했는지 등을 Kernel 내부에서 직접 확인할 수 있다.

또한 네트워크 패킷을 User Space 까지 올리지 않고 Kernel 내부에서 바로 처리할 수 있기 때문에 성능 측면에서도 장점이 있다.

eBPF 의 전체 구조

eBPF 의 전체 구조는 대략 다음과 같이 볼 수 있다.

User Space
    - eBPF Loader
    - Policy Manager
    - Event Reader
    - CLI / GUI
    - Metrics Collector

Kernel Space
    - eBPF Program
    - eBPF Map
    - Verifier
    - JIT Compiler
    - Hook Point
    - Helper Function

User Space 에서는 eBPF Program 을 로드하고, Map 을 관리하고, Kernel 에서 전달되는 이벤트를 읽는다.

Kernel Space 에서는 eBPF Program 이 Hook Point 에서 실행되고, Map 에 데이터를 저장하거나 Helper Function 을 호출한다.

이 둘은 bpf() syscall, Map, Ring Buffer 등을 통해 상호작용한다.

즉, eBPF 는 User Space 의 제어 프로그램과 Kernel Space 의 eBPF Program 이 함께 동작하는 구조이다.

정리

eBPF 는 Linux Kernel 내부에서 안전하게 실행되는 작은 프로그램을 이용해 Kernel 기능을 동적으로 확장하는 기술이다.

초기 BPF 는 네트워크 패킷 필터링을 위한 기술이었지만, eBPF 는 이를 확장해서 네트워크, 관측성, 보안, 성능 분석 등 다양한 분야에서 사용될 수 있게 되었다.

eBPF Program 은 Kernel 에 로드되기 전에 Verifier 의 검사를 받아야 하고, 검증을 통과한 뒤 특정 Hook Point 에 Attach 되어 이벤트가 발생할 때 실행된다.

eBPF 의 핵심 구성 요소는 다음과 같다.

  • eBPF Program
  • Hook Point
  • Program Type
  • Verifier
  • JIT Compiler
  • Helper Function
  • eBPF Map
  • Loader
  • Ring Buffer
  • BTF / CO-RE

'DevSec' 카테고리의 다른 글

TLB-Hit Model  (0) 2026.06.13
eBPF for Windows  (0) 2026.06.11
BPF  (0) 2026.06.10
Mutual Exclusion  (0) 2026.06.06
Critical Section  (0) 2026.06.06

티스토리툴바