Microsoft MVP성태의 닷넷 이야기
Linux: 96. eBPF (bpf2go) - fentry, fexit를 이용한 트레이스 [링크 복사], [링크+제목 복사],
조회: 4428
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 

(시리즈 글이 14개 있습니다.)
Linux: 86. Golang + bpf2go를 사용한 eBPF 기본 예제
; https://www.sysnet.pe.kr/2/0/13769

Linux: 94. eBPF - vmlinux.h 헤더 포함하는 방법 (bpf2go에서 사용)
; https://www.sysnet.pe.kr/2/0/13783

Linux: 95. eBPF - kprobe를 이용한 트레이스
; https://www.sysnet.pe.kr/2/0/13784

Linux: 96. eBPF (bpf2go) - fentry, fexit를 이용한 트레이스
; https://www.sysnet.pe.kr/2/0/13788

Linux: 100.  eBPF의 2가지 방식 - libbcc와 libbpf(CO-RE)
; https://www.sysnet.pe.kr/2/0/13801

Linux: 103. eBPF (bpf2go) - Tracepoint를 이용한 트레이스 (BPF_PROG_TYPE_TRACEPOINT)
; https://www.sysnet.pe.kr/2/0/13810

Linux: 105. eBPF - bpf2go에서 전역 변수 설정 방법
; https://www.sysnet.pe.kr/2/0/13815

Linux: 106. eBPF / bpf2go - (BPF_MAP_TYPE_HASH) Map을 이용한 전역 변수 구현
; https://www.sysnet.pe.kr/2/0/13817

Linux: 107. eBPF - libbpf CO-RE의 CONFIG_DEBUG_INFO_BTF 빌드 여부에 대한 의존성
; https://www.sysnet.pe.kr/2/0/13819

Linux: 109. eBPF / bpf2go - BPF_PERF_OUTPUT / BPF_MAP_TYPE_PERF_EVENT_ARRAY 사용법
; https://www.sysnet.pe.kr/2/0/13824

Linux: 110. eBPF / bpf2go - BPF_RINGBUF_OUTPUT / BPF_MAP_TYPE_RINGBUF 사용법
; https://www.sysnet.pe.kr/2/0/13825

Linux: 115. eBPF (bpf2go) - ARRAY / HASH map 기본 사용법
; https://www.sysnet.pe.kr/2/0/13893

Linux: 116. eBPF / bpf2go - BTF Style Maps 정의 구문과 데이터 정렬 문제
; https://www.sysnet.pe.kr/2/0/13894

Linux: 117. eBPF / bpf2go - Map에 추가된 요소의 개수를 확인하는 방법
; https://www.sysnet.pe.kr/2/0/13895




eBPF (bpf2go) - fentry, fexit를 이용한 트레이스

지난 글에서 kprobe 방식을 살펴봤는데요,

eBPF - kprobe를 이용한 트레이스
; https://www.sysnet.pe.kr/2/0/13784

kprobe의 경우 int 3(0xcc) BP에 따른 오버헤드가 발생하는 문제점이 있는 반면 fentry, fexit 방식은 성능 손실이 적다고 합니다. 기술적인 차이를 보면 그 이유를 알 수 있는데요,

Program type BPF_PROG_TYPE_TRACING - Fentry
; https://docs.ebpf.io/linux/program-type/BPF_PROG_TYPE_TRACING/#fentry

Fentry programs are attached to a BPF trampoline which causes less overhead than kprobes. Fentry programs can also be attached to BPF programs such as XDP, TC or cGroup programs which makes debugging eBPF programs easier. Kprobes lack this capability.


정리해 보면, kprobe와는 다르게 fentry, fexit 방식은 trampoline 기법을 이용하기 때문에 직접적인 함수 호출에 준하는 오버헤드만 있기 때문입니다.
Extracting kprobe parameters in eBPF
; https://eyakubovich.github.io/2022-04-19-ebpf-kprobe-params/

그 외에 성능과는 별개로 kretprobe와 fexit의 인자 수가 다르다는 차이가 있는데요, 기존의 kretprobe는 함수의 반환값만을 eBPF 함수에서 받을 수 있었지만 fexit의 경우에는 fentry의 입력 인자를 중복해서 받게 됩니다.

eBPF Tutorial by Example 3: Monitoring unlink System Calls with fentry
; https://eunomia.dev/en/tutorials/3-fentry-unlink/

The main difference between fexit and kretprobe programs is that fexit programs can access both the input parameters and return values of a function, while kretprobe programs can only access the return value.


libbpf-bootstrap: demo BPF applications - fentry
; https://github.com/libbpf/libbpf-bootstrap/blob/master/README.md#fentry

Important differences, compared to kprobes, are improved performance and usability. In this example, better usability is shown with the ability to directly dereference pointer arguments, like in normal C, instead of using various read helpers. The big distinction between fexit and kretprobe programs is that fexit one has access to both input arguments and returned result, while kretprobe can only access the result.


참고로, fentry, fexit 방식은 5.5 버전부터 사용 가능합니다.




구현의 차이는 있어도, 사용하는 방식 자체는 크게 다르지 않습니다. kprobe와 마찬가지로 fentry도 커널 함수를 대상으로 하기 때문에 대상을 찾는 것도 bpftrace 도구에서는 kprobe로 검색할 수 있습니다.

$ sudo bpftrace -l 'kprobe:*tcp_connect'
kprobe:ceph_tcp_connect
kprobe:tcp_connect

대상이 결정되었다면 그것의 함수 원형을 알아내야 하고,

tcp_connect (/net/ipv4/tcp_output.c)
; https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_output.c#L4065

// 함수 원형
int tcp_connect(struct sock *sk);

이에 기반해 eBPF 코드를 다음과 같은 식으로 만들 수 있습니다.

//go:build ignore

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

SEC("fentry/tcp_connect")
int BPF_PROG(tcp_connect, struct sock *sk)
{
    pid_t tgid = bpf_get_current_pid_tgid() >> 32;
    bpf_printk("fentry-tcp_connect: pid = %d\n", tgid);
    return 0;
}

SEC("fexit/tcp_connect")
int BPF_PROG(tcp_connect_exit, struct sock *sk, int ret)
{
    pid_t tgid = bpf_get_current_pid_tgid() >> 32;
    bpf_printk("fexit-tcp_connect: pid = %d, ret = %ld\n", tgid, ret);
    return 0;
}

char __license[] SEC("license") = "GPL";

보는 바와 같이 SEC의 이름 지정도 살짝 달라졌는데요, 이에 대한 Prefix 종류는 다음의 문서에 나와 있습니다.

Section Naming - Program Sections
; https://ebpf-go.dev/concepts/section-naming/#program-sections

Section(Prefix) ProgramType AttachType
...[생략]...
kprobe          Kprobe
...[생략]...
fentry          Tracing     AttachTraceFEntry

위의 표에 나온 kprobe, fentry의 ProgramType과 AttachType이 다른데요, 이것은 이후 "go generate"로 만들어진 자동 생성 코드를 이용해 연결할 때도 참고하게 됩니다. 가령, 지난 예제 코드에서 kprobe는 이렇게 연결했었는데요,

kp, err := link.Kprobe(kprobeFunc, bpfObj.KprobeSysClone, nil)

반면 Fentry 예제에서는 AttachTracing 메서드를 이용하게 됩니다.

package main

//go:generate go run github.com/cilium/ebpf/cmd/bpf2go ebpf_basic basic.c

import (
    "bufio"
    "fmt"
    "github.com/cilium/ebpf/link"
    "github.com/cilium/ebpf/rlimit"
    "log"
    "os"
)

func requirePrerequisites() {
    // ...[생략]...
}

func main() {
    fmt.Println("hello world v4")

    requirePrerequisites()

    var bpfObj ebpf_basicObjects               // bpf2go로 자동 생성된 타입
    err := loadEbpf_basicObjects(&bpfObj, nil) // bpf2go로 자동 생성된 함수
    if err != nil {
        fmt.Printf("objs == null, %v\n", err)
        return
    }
    defer func(bpfObj *ebpf_basicObjects) {
        fmt.Printf("bpfObj.defer\n")
        _ = bpfObj.Close()
    }(&bpfObj)

    fmt.Printf("loaded: %v\n", bpfObj)


    // AttachTracing links a tracing (fentry/fexit/fmod_ret) BPF program or
    // a BTF-powered raw tracepoint (tp_btf) BPF Program to a BPF hook defined
    // in kernel modules.
    {
        // https://github.com/cilium/ebpf/blob/v0.16.0/link/tracing.go#L195
        fp, err := link.AttachTracing(link.TracingOptions{
            Program: bpfObj.ebpf_basicPrograms.TcpConnect,
        })
        if err != nil {
            fmt.Printf("fp == null, %v\n", err)
            return
        }
        defer func(kp link.Link) {
            fmt.Printf("link.tcp_connect.defer\n")
            _ = kp.Close()
        }(fp)

        fmt.Printf("link.Fentry: %v\n", fp)
    }

    {
        fp, err := link.AttachTracing(link.TracingOptions{
            Program: bpfObj.ebpf_basicPrograms.TcpConnectExit,
        })
        if err != nil {
            fmt.Printf("fp == null, %v\n", err)
            return
        }
        defer func(kp link.Link) {
            fmt.Printf("link.tcp_connect.exit.defer\n")
            _ = kp.Close()
        }(fp)

        fmt.Printf("link.Fexit: %v\n", fp)
    }

    fmt.Println("Press any key to exit...")
    input := bufio.NewScanner(os.Stdin)
    input.Scan()
}

빌드 후 실행해 보면, bpf_printk 출력으로 잘 동작하는 것을 확인할 수 있습니다.

$ sudo cat /sys/kernel/debug/tracing/trace_pipe
kubelet-3903    [000] ...11 259090.102895: bpf_trace_printk: fentry-tcp_connect: pid = 3181
kubelet-3903    [000] ...11 259090.103049: bpf_trace_printk: fexit-tcp_connect: pid = 3181, ret = 0
coredns-6010    [003] ...11 259090.337794: bpf_trace_printk: fentry-tcp_connect: pid = 5239
coredns-6010    [003] ...11 259090.337868: bpf_trace_printk: fexit-tcp_connect: pid = 5239, ret = 0
coredns-5856    [007] ...11 259090.338179: bpf_trace_printk: fentry-tcp_connect: pid = 5264
coredns-5856    [007] ...11 259090.338209: bpf_trace_printk: fexit-tcp_connect: pid = 5264, ret = 0
kubelet-3908    [006] ...11 259090.533112: bpf_trace_printk: fentry-tcp_connect: pid = 3181
kubelet-3908    [006] ...11 259090.533220: bpf_trace_printk: fexit-tcp_connect: pid = 3181, ret = 0
...[생략]...




작성한 eBPF 코드가 이런 오류가 발생한다면?

field TcpConnect: program tcp_connect: apply CO-RE relocations: load kernel spec: btf: not found

검색 결과,

program: relocation of program targeting a module fails if CONFIG_DEBUG_INFO_BTF_MODULES is disabled #1436
; https://github.com/cilium/ebpf/issues/1436

CONFIG_DEBUG_INFO_BTF_MODULES 옵션이 커널 빌드 시에 적용되지 않았다고 합니다. 실제로 이와 관련한 디렉터리도 없는데요,

// 동작하지 않는 환경의 경우

$ ls /sys/kernel/btf
ls: cannot access '/sys/kernel/btf': No such file or directory

예제에서 요구하는 BTF 정보는 vmlinux이기 때문에 최소한 /sys/kernel/btf 디렉터리에 vmlinux 파일은 있어야 합니다.

// 잘 동작하는 환경의 경우

$ ll /sys/kernel/btf/vmlinux
-r--r--r-- 1 root root 5866532 Oct 25 12:59 /sys/kernel/btf/vmlinux

참고로, 문제가 있는 리눅스 배포본의 해당 커널이 빌드된 config 파일에 CONFIG_DEBUG_INFO_BTF_MODULES 옵션 설정이 없습니다.

// 동작하지 않는 환경의 경우

$ cat /boot/config-$(uname -r) | grep CONFIG_DEBUG_INFO_BTF_MODULES
$

정상적이라면 이렇게 y 설정이 있어야 합니다.

$ cat /boot/config-$(uname -r) | grep CONFIG_DEBUG_INFO_BTF_MODULES
CONFIG_DEBUG_INFO_BTF_MODULES=y




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 11/12/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13868정성태1/17/20253090Windows: 277. Hyper-V - Windows 11 VM의 Enhanced Session 모드로 로그인을 할 수 없는 문제
13867정성태1/17/20254031오류 유형: 943. Hyper-V에 Windows 11 설치 시 "This PC doesn't currently meet Windows 11 system requirements" 오류
13866정성태1/16/20254229개발 환경 구성: 739. Windows 10부터 바뀐 device driver 서명 방법
13865정성태1/15/20253926오류 유형: 942. C# - .NET Framework 4.5.2 이하의 버전에서 HttpWebRequest로 https 호출 시 "System.Net.WebException" 예외 발생
13864정성태1/15/20253877Linux: 114. eBPF를 위해 필요한 SELinux 보안 정책
13863정성태1/14/20253327Linux: 113. Linux - 프로세스를 위한 전용 SELinux 보안 문맥 지정
13862정성태1/13/20253600Linux: 112. Linux - 데몬을 위한 SELinux 보안 정책 설정
13861정성태1/11/20253904Windows: 276. 명령행에서 원격 서비스를 동기/비동기로 시작/중지
13860정성태1/10/20253586디버깅 기술: 216. WinDbg - 2가지 유형의 식 평가 방법(MASM, C++)
13859정성태1/9/20253939디버깅 기술: 215. Windbg - syscall 이후 실행되는 KiSystemCall64 함수 및 SSDT 디버깅
13858정성태1/8/20254086개발 환경 구성: 738. PowerShell - 원격 호출 시 "powershell.exe"가 아닌 "pwsh.exe" 환경으로 명령어를 실행하는 방법
13857정성태1/7/20254120C/C++: 187. Golang - 콘솔 응용 프로그램을 Linux 데몬 서비스를 지원하도록 변경파일 다운로드1
13856정성태1/6/20253698디버깅 기술: 214. Windbg - syscall 단계까지의 Win32 API 호출 (예: Sleep)
13855정성태12/28/20244427오류 유형: 941. Golang - os.StartProcess() 사용 시 오류 정리
13854정성태12/27/20244528C/C++: 186. Golang - 콘솔 응용 프로그램을 NT 서비스를 지원하도록 변경파일 다운로드1
13853정성태12/26/20244007디버깅 기술: 213. Windbg - swapgs 명령어와 (Ring 0 커널 모드의) FS, GS Segment 레지스터
13852정성태12/25/20244452디버깅 기술: 212. Windbg - (Ring 3 사용자 모드의) FS, GS Segment 레지스터파일 다운로드1
13851정성태12/23/20244215디버깅 기술: 211. Windbg - 커널 모드 디버깅 상태에서 사용자 프로그램을 디버깅하는 방법
13850정성태12/23/20244710오류 유형: 940. "Application Information" 서비스를 중지한 경우, "This file does not have an app associated with it for performing this action."
13849정성태12/20/20244851디버깅 기술: 210. Windbg - 논리(가상) 주소를 Segmentation을 거쳐 선형 주소로 변경
13848정성태12/18/20244804디버깅 기술: 209. Windbg로 알아보는 Prototype PTE파일 다운로드2
13847정성태12/18/20244823오류 유형: 939. golang - 빌드 시 "unknown directive: toolchain" 오류 빌드 시 이런 오류가 발생한다면?
13846정성태12/17/20245038디버깅 기술: 208. Windbg로 알아보는 Trans/Soft PTE와 2가지 Page Fault 유형파일 다운로드1
13845정성태12/16/20244508디버깅 기술: 207. Windbg로 알아보는 PTE (_MMPTE)
13844정성태12/14/20245174디버깅 기술: 206. Windbg로 알아보는 PFN (_MMPFN)파일 다운로드1
13843정성태12/13/20244366오류 유형: 938. Docker container 내에서 빌드 시 error MSB3021: Unable to copy file "..." to "...". Access to the path '...' is denied.
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...