어제(Day 1)는 툴체인을 세팅하고 vmlinux.h를 만들어보고, kprobe 하나가 커널 함수 이름이 바뀌어서 실패하는 걸 직접 겪으며 CO-RE와 verifier의 실체를 확인하는 날이었다. 오늘은 그 위에서 실제로 "컨테이너 프로세스를 추적한다"는 게 커널 레벨에서 무슨 의미인지 파고들고, 실제로 동작하는 코드까지 완성한 날이다.목표는 단순했다. mycontainer로 컨테이너를 하나 띄웠을 때, 그 안에서 새 프로세스가 실행될 때마다 커널이 그 사실을 잡아채서, "이게 어느 컨테이너의 몇 번 프로세스인지"를 유저스페이스로 실시간 전달하는 것.왜 kprobe가 아니라 tracepoint인가어제 겪은 문제를 다시 떠올려보자. do_unlinkat이라는 커널 함수를 kprobe로 걸었는데, 이 커널..

컨테이너를 eBPF로 관측하는 최소 데모를 만들기로 했다. 첫날(Day 1)의 목표는 화려한 기능을 만드는 게 아니라 기반을 다지는 것 — 개발 파이프라인이 실제로 도는지 검증하고, 지난 주 애매하게 넘어갔던 verifier와 BTF/CO-RE 개념을 실제 에러 메시지를 보면서 다시 확인하는 날이었다. 결과적으로는 단순한 복습이 아니라, __attribute__가 뭔지, BTF가 뭔지, verifier가 정확히 뭘 증명하는지까지 꽤 깊이 파고든 하루가 됐다.vmlinux.h 만들기 — CO-RE를 체감하다/sys/kernel/btf/vmlinux를 cat으로 열어보면 깨진 문자만 나온다. 이 파일은 텍스트가 아니라 바이너리 타입 그래프이기 때문이다. 커널의 모든 타입(struct, union, 함수 등)..

/* ------------------------------------------------------------------ * 실제 커널 구조체를 단순화한 버전. 필드 몇 개만 뽑아서 * task_struct / struct pid / pid_namespace가 서로 어떻게 연결되는지 * "관계"만 보여주기 위한 것. 컴파일 가능한 코드가 아님. * ------------------------------------------------------------------ *//* (1) 프로세스 하나를 나타내는 핵심 구조체 */struct task_struct { struct pid *thread_pid; /* ★ 이 프로세스의 "신원 정보"가 담긴 struct pid를 가리킴 */ str..

툴체인을 세팅하고 libbpf-bootstrap의 kprobe 예제를 실제로 빌드·attach하는 과정에서, vmlinux.h 한 줄을 계기로 __attribute__/매크로/BTF/CO-RE까지 파고들었고, 마지막엔 일부러 verifier 에러를 내보다가 verifier가 실제로 어떻게 "증명"을 하는지까지 확인하게 된 기록. ebpf-kprobe-macro-pointer.md(BPF_KPROBE 매크로, PT_REGS, BPF_CORE_READ 편)에서 이어지는 실습.1. __attribute__는 매크로가 아니다 — SEC()는 매크로다이 둘을 구분하는 게 이후 모든 내용의 기반이 된다.__attribute__는 표준 C 문법이 아니라 GCC가 만든 확장이고, clang이 호환을 위해 그대로 구현한..

libbpf-bootstrap의 kprobe.bpf.c 예제를 읽다가 BPF_KPROBE라는 매크로 한 줄에 걸려 넘어졌다. "이거 그냥 함수 아니야?"라는 질문에서 시작해서, C 매크로의 동작 원리, 포인터/역참조, 커널 레지스터와 호출 규약까지 파고든 기록.원본 코드// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause#include "vmlinux.h"#include #include #include char LICENSE[] SEC("license") = "Dual BSD/GPL";SEC("kprobe/do_unlinkat")int BPF_KPROBE(do_unlinkat, int dfd, struct filename *name){ pid_t pid; ..

최소 컨테이너 런타임 완성1주차부터 6주차까지, namespace 기초부터 시작해서 mount 격리, cgroup 리소스 제한, 네트워킹, OverlayFS, 그리고 이번 주 lifecycle 관리까지 붙이면서 "동작하는 최소 컨테이너 런타임" 하나를 완성했다. 이번 글에서는 지금까지 만든 게 정확히 뭘 할 수 있는지, 그리고 전체 기능을 이어서 돌려본 통합 테스트 결과를 정리한다.지금까지 쌓아온 것1주차: UTS/PID namespace로 hostname과 PID 격리2주차: pivot_root로 rootfs 격리 (chroot의 한계를 직접 탈출해보며 확인)3주차: cgroup v2로 memory/cpu/pids 제한4주차: veth + bridge + NAT로 컨테이너 네트워킹5주차: Overlay..