ARI

eBPF 프로그램은 일반적으로 프로세스가 종료되면 함께 제거됩니다. 또한 eBPF 프로그램이 사용하는 BPF Map 역시 해당 프로그램과 함께 해제되는 경우가 많습니다. 하지만 실제 운영 환경에서는 프로그램을 다시 로드하지 않고도 BPF Map을 계속 유지하거나, 여러 프로세스가 동일한 eBPF 프로그램과 Map을 공유해야 하는 경우가 자주 발생합니다. 이러한 문제를 해결하기 위해 Linux는 eBPF Pinning(Pinned Object) 기능을 제공합니다. Pinning을 사용하면 … 더 읽기

과거에는 eBPF 프로그램을 작성한 후 커널에 로드하기 위해 수백 줄 이상의 C 코드를 직접 작성해야 했습니다. ELF 파일을 열고, Map을 생성하고, 프로그램을 로드한 뒤 Hook에 연결하는 작업을 모두 개발자가 구현해야 했기 때문입니다. 이러한 복잡함을 해결하기 위해 libbpf Skeleton이 등장했습니다. Skeleton은 bpftool이 자동으로 생성하는 C 헤더 파일로, eBPF 프로그램을 매우 간단하게 로드하고 관리할 수 있도록 만들어 … 더 읽기

eBPF 프로그램은 C 언어로 작성한 후 컴파일만 한다고 바로 실행되는 것이 아닙니다. 컴파일된 eBPF Object 파일을 Linux Kernel에 등록하고, Verifier 검사를 거친 뒤 적절한 Hook에 연결해야 비로소 실행됩니다. 이 모든 과정을 담당하는 것이 eBPF Loader입니다. 초기의 eBPF 개발에서는 직접 BPF System Call을 호출하여 프로그램을 로드했지만, 현재는 대부분 libbpf Loader를 사용합니다. libbpf Loader는 프로그램 로드뿐 아니라 … 더 읽기

eBPF 프로그램은 모두 같은 방식으로 실행되는 것이 아닙니다. 어떤 프로그램은 네트워크 패킷을 처리하고, 어떤 프로그램은 시스템 콜을 추적하며, 또 다른 프로그램은 파일 시스템이나 보안 이벤트를 감시합니다. 이처럼 eBPF 프로그램이 어디에 연결(Hook)되어 어떤 목적으로 실행되는지를 정의하는 것이 Program Type입니다. Program Type에 따라 사용할 수 있는 Helper Function, 접근 가능한 데이터, 연결 가능한 Hook, 실행 시점 등이 … 더 읽기

eBPF 프로그램은 커널 내부에서 실행되지만, 프로그램 자체에는 큰 데이터를 저장하거나 상태를 유지할 수 있는 공간이 거의 없습니다. 또한 여러 eBPF 프로그램이 데이터를 공유하거나 사용자 공간(User Space)과 정보를 교환하기 위해서는 별도의 저장 공간이 필요합니다. 이 역할을 담당하는 것이 BPF Map입니다. 하지만 BPF Map은 하나의 종류만 존재하는 것이 아닙니다. 저장 방식과 목적에 따라 Hash Map, Array Map, … 더 읽기

eBPF 프로그램은 Linux Kernel 내부에서 실행되지만 일반적인 커널 코드처럼 모든 함수나 메모리에 자유롭게 접근할 수는 없습니다. 이는 시스템 안정성과 보안을 유지하기 위한 중요한 설계 원칙입니다. 그렇다면 eBPF 프로그램은 현재 시간, 프로세스 정보, 네트워크 패킷, CPU 정보와 같은 데이터를 어떻게 가져올까요? 바로 BPF Helper Function(헬퍼 함수) 을 사용합니다. BPF Helper Function은 Linux Kernel이 공식적으로 제공하는 API로, … 더 읽기

eBPF는 Linux Kernel 내부에서 직접 실행되는 프로그램입니다. 만약 잘못 작성된 eBPF 프로그램이 커널에서 실행된다면 시스템이 멈추거나(Kernel Panic), 메모리가 손상되거나, 보안 취약점이 발생할 수 있습니다. 이러한 위험을 방지하기 위해 Linux Kernel에는 eBPF Verifier라는 강력한 검증 엔진이 내장되어 있습니다. Verifier는 eBPF 프로그램이 커널에 로드되기 전에 코드를 분석하여 안전성을 검증합니다. 안전하지 않다고 판단되면 프로그램은 실행되지 않으며, 커널은 이를 … 더 읽기

eBPF 프로그램은 Linux Kernel 내부에서 다양한 이벤트를 수집할 수 있습니다. 하지만 커널에서 생성된 데이터를 사용자 공간(User Space)의 프로그램으로 안전하고 빠르게 전달하는 메커니즘이 필요합니다. 초기 eBPF 환경에서는 Perf Buffer(Perf Event Buffer) 가 표준적인 데이터 전달 방식으로 사용되었습니다. Perf Buffer는 Linux의 Performance Monitoring Infrastructure를 기반으로 만들어졌으며, 오랫동안 BCC와 bpftrace 같은 도구에서 기본 데이터 전달 방식으로 활용되었습니다. 최근에는 … 더 읽기

eBPF 프로그램은 Linux Kernel 내부에서 실행되기 때문에 다양한 정보를 수집할 수 있습니다. 하지만 수집한 데이터를 사용자 공간(User Space)의 프로그램으로 전달하지 못하면 분석 결과를 확인하거나 활용할 수 없습니다. 초기의 eBPF에서는 Perf Event Buffer(Perf Buffer) 를 주로 사용하여 데이터를 전달했습니다. 그러나 Perf Buffer는 이벤트 처리 비용이 크고 CPU 간 데이터 이동이 많아 대량의 이벤트를 처리할 때 성능 … 더 읽기

최근 Linux eBPF 개발은 대부분 libbpf를 중심으로 이루어지고 있습니다. 과거에는 BCC(BPF Compiler Collection)가 많이 사용되었지만, 현재는 Linux Kernel 개발팀이 권장하는 방식이 libbpf + CO-RE 조합입니다. libbpf는 eBPF 프로그램을 컴파일하고 커널에 로드하며, BPF Map과 Hook을 관리하는 기능을 제공하는 공식 라이브러리입니다. 특히 CO-RE(Compile Once – Run Everywhere)를 지원하여 하나의 eBPF 프로그램을 다양한 Linux Kernel에서 실행할 수 있도록 … 더 읽기