eBPF / bpf2go - BPF_RINGBUF_OUTPUT / BPF_MAP_TYPE_RINGBUF 사용법
지난 글에서 BPF_MAP_TYPE_PERF_EVENT_ARRAY 사용법을 알아봤는데요,
eBPF / bpf2go - BPF_PERF_OUTPUT / BPF_MAP_TYPE_PERF_EVENT_ARRAY 사용법
; https://www.sysnet.pe.kr/2/0/13824
이번에는 같은 stream map 방식의 BPF_MAP_TYPE_RINGBUF도 마저 살펴보겠습니다.
Map type BPF_MAP_TYPE_RINGBUF (커널 5.8부터 구현)
; https://docs.ebpf.io/linux/map-type/BPF_MAP_TYPE_RINGBUF/
우선 BPF_MAP_TYPE_RINGBUF 타입의 경우 개념적으로는 BPF_MAP_TYPE_PERF_EVENT_ARRAY의 개선된 버전이라고 보시면 됩니다. 아래는 일반적인 BPF_MAP_TYPE_RINGBUF 정의를 보여주는데요,
struct {
__uint(type, BPF_MAP_TYPE_RINGBUF);
__uint(max_entries, 64 * 4096);
} task_creation_events SEC(".maps");
/* libbcc 방식이었다면 BPF_RINGBUF_OUTPUT 매크로를 이용해 정의합니다.
5. BPF_RINGBUF_OUTPUT
; https://github.com/iovisor/bcc/blob/master/docs/reference_guide.md#5-bpf_ringbuf_output
*/
BPF_MAP_TYPE_PERF_EVENT_ARRAY와는 달리 key_size, value_size가 무조건 0이어야 한다고 해서 그런지 정의에서 생략하게 됩니다. 또한 BPF_MAP_TYPE_PERF_EVENT_ARRAY는 맵의 크기를 사용하는 측에서 결정했는데, BPF_MAP_TYPE_RINGBUF는 eBPF 코드에서 결정한다는 차이점이 있습니다.
또한, 아래의 글에 보면 클라이언트 측에서 결정하는 방법도 제공한다고 하는데요,
(제가 방법을 모르는 걸 수도 있지만) 현재 bpf2go에서는 max_entries를 생략하는 경우 자동 생성 코드 단계는 통과하지만 eBPF 코드 로딩 시에 이런 오류가 발생합니다.
/*
struct {
__uint(type, BPF_MAP_TYPE_RINGBUF);
} task_creation_events SEC(".maps");
*/
map create: invalid argument (MaxEntries may be incorrectly set to zero)
여하튼 이렇게 정의하는 max_entries의 제약 사항이라면,
Page 크기의 배수이면서 2의 n승이어야 한다는 제약이 있습니다. 위의 예제는 64개의 페이지 크기, 262,144 바이트니까 2
18을 만족합니다.
BPF_MAP_TYPE_RINGBUF에 대해 사용 가능한 함수는
문서에서 "Ring buffer helper"로 분류된 함수만 가능합니다.
- bpf_ringbuf_output
- bpf_ringbuf_reserve
- bpf_ringbuf_submit
- bpf_ringbuf_discard
- bpf_ringbuf_query
- bpf_ringbuf_reserve_dynptr
- bpf_ringbuf_submit_dynptr
- bpf_ringbuf_discard_dynptr
우선 쓰기 관련해서는 크게 2가지 방식으로 나뉘는데요,
bpf_ringbuf_output은 BPF_MAP_TYPE_PERF_EVENT_ARRAY 방식의 관행을 따라 제공하는 함수인 반면, reserve/submit은 BPF_MAP_TYPE_RINGBUF 전용 방식에 해당합니다.
따라서 bpf_ringbuf_output의 방식이 손쉬운 마이그레이션을 제공하긴 해도 비효율적인 동작을 하게 되는데, 일례로 클라이언트로 보낼 버퍼가 소진돼 더 이상 쓸 수 없는 상황에서도 여전히 bpf_ringbuf_output는 이벤트 기록을 위한 메모리도, 또한 그 메모리에 값을 채워야 하는 동작도 모두 완료돼 있어야 합니다.
그런 문제를 해결하는 방법이 바로 reserve/submit 방식인데요, 우선 현재의 이벤트를 기록할 수 있는 공간을 확보할 수 있는지를 알아보고 (reserve), 확보가 된 경우에만 이후 이벤트를 구성하는 코드를 수행해 submit하는 코드를 진행하도록 코딩할 수 있습니다. 일례로, 지난 글의 BPF_MAP_TYPE_PERF_EVENT_ARRAY 코드를 BPF_MAP_TYPE_RINGBUF로 바꾸면 대충 이렇게 구현할 수 있습니다.
// eBPF Tutorial by Example 8: Monitoring Process Exit Events, Output with Ring Buffer
// https://eunomia.dev/en/tutorials/8-exitsnoop/
struct {
__uint(type, BPF_MAP_TYPE_RINGBUF);
__uint(max_entries, 64 * 4096);
} task_creation_events SEC(".maps");
#define TASK_COMM_LEN 32
struct task_creation_info {
uint32_t pid;
uint32_t ppid;
uint32_t uid;
char comm[TASK_COMM_LEN];
};
SEC("tracepoint/syscalls/sys_enter_execve")
int sys_enter_execve(struct trace_event_raw_sys_enter* ctx)
{
struct task_creation_info *item = bpf_ringbuf_reserve(&task_creation_events, sizeof(*item), 0);
if (item == NULL)
{
return 0;
}
struct task_struct *task = (struct task_struct*)bpf_get_current_task();
u64 pid_tgid = bpf_get_current_pid_tgid();
item->pid = pid_tgid >> 32;
item->ppid = BPF_CORE_READ(task, real_parent, tgid);
uid_t uid = (u32)bpf_get_current_uid_gid();
item->uid = uid;
char *cmd_ptr = (char *) BPF_CORE_READ(ctx, args[0]);
bpf_probe_read_str(&item->comm, sizeof(item->comm), cmd_ptr);
bpf_ringbuf_submit(item, 0);
return 0;
}
BPF_MAP_TYPE_PERF_EVENT_ARRAY 예제의 경우와는 달리, ringbuf에 공간이 없다면 그 이후의 데이터 처리 과정은 조기에 "return 0"으로 벗어날 수 있는 장점은 제공하고 있습니다.
eBPF 측의 마이그레이션을 저렇게 끝냈다면, 이제 클라이언트 측을 손봐야 하는데요, 다행히 (bpf2go 덕분에) go 측의 코드도 거의 바뀌는 점은 없습니다. 단지 NewReader를 호출하는 패키지만 perf가 아닌 ringbuf로 바뀌는 정도의 간단한 변경만 하면 됩니다.
func ReadExeCve(bpfObj ebpf_basicObjects) {
rd, err := ringbuf.NewReader(bpfObj.TaskCreationEvents)
// ...[생략: BPF_MAP_TYPE_PERF_EVENT_ARRAY 방식과 동일]...
for {
// ...[생략: BPF_MAP_TYPE_PERF_EVENT_ARRAY 방식과 동일]...
}
}
실행해 보면, 이전의 BPF_MAP_TYPE_PERF_EVENT_ARRAY를 사용했던 코드와 정확히 동일한 출력 결과를 얻을 수 있습니다.
보다 자세한 BPF_MAP_TYPE_PERF_EVENT_ARRAY, BPF_MAP_TYPE_RINGBUF의 차이점은 아래의 글에서 잘 설명하고 있으니 참고하시고,
BPF ring buffer
; https://nakryiko.com/posts/bpf-ringbuf/#bpf-ringbuf-bpf-ringbuf-output
단지, CPU마다 개별 할당되는 BPF_MAP_TYPE_PERF_EVENT_ARRAY는 몇 가지 단점이 존재하는데요,
이런 문제를 해결한 것이 BPF_MAP_TYPE_RINGBUF이므로 커널 버전이 5.8이라는 제약만 없다면
BPF_MAP_TYPE_RINGBUF를 사용하는 것이 더 성능에 좋습니다.. 따라서 가능한 마이그레이션을 권장하는데요, 문제는 커널 버전이 범용적으로 쓰기에는 아직 제약이 있습니다. 가령 2022년 4월에 나온 Ubuntu 22.04의 5.15 커널 버전이고, 그보다 앞선 2020년 4월에 나온 Ubuntu 20.04가 5.4 버전을 사용하고 있으니 대략 어느 정도의 배포판에서 사용 가능한지 가늠할 수 있을 것입니다.
아래의 글을 보면,
An Applied Introduction to eBPF with Go
; https://edgedelta.com/company/blog/applied-introduction-ebpf-go
BPF_MAP_TYPE_RINGBUF의 max_entries를 (page 크기의 배수가 아닌) 1000으로 설정한 예제가 있습니다.
struct {
__uint(type, BPF_MAP_TYPE_RINGBUF);
__uint(max_entries, 1000);
} events SEC(".maps");
아마도 저렇게 설정해도 되는 시절이 있었는지는 모르겠지만, 현재는 bpf2go의 경우 로딩 시에 이런 오류가 발생합니다.
field SysEnterExecve: program sys_enter_execve: map task_creation_events: map create: invalid argument (ring map size 1024 not a multiple of page size 4096)
아울러 아래의 예제는,
eBPF Tutorial by Example 8: Monitoring Process Exit Events, Print Output with Ring Buffer
; https://medium.com/@yunwei356/ebpf-tutorial-by-example-8-monitoring-process-exit-events-print-output-with-ring-buffer-73291d5e3a50
struct {
__uint(type, BPF_MAP_TYPE_RINGBUF);
__uint(max_entries, 256 * 1024);
} rb SEC(".maps");
다행히 256을 곱했기 때문에 운이 좋았군요. ^^ 만약 3, 5, ... 등의 수를 곱했다면 오류가 발생했을 겁니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]