1 #include "vmlinux.h" 2 #include 3 #include 4 5 char LICENSE[] SEC("license") = "Dual BSD/GPL"; 6 7 struct { 8 __uint(type, BPF_MAP_TYPE_HASH); 9 __uint(max_entries, 1); 10 __type(key, __u32); 11 __type(value, __u64); 12 } test_map SEC(".maps"); 13 14 SEC("kprobe/__arm64_sys_unlinkat") 15 int BPF_KPROBE(bad_verifier_test) 16 { 17 __u32 key = 0; 18 __u64 *value;..

/* ------------------------------------------------------------------ * 실제 커널 구조체를 단순화한 버전. 필드 몇 개만 뽑아서 * 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..

docker exec는 내부적으로 어떻게 동작하는가docker exec는 이미 떠 있는 컨테이너 안에 들어가서 명령을 실행하는, 아주 자주 쓰는 명령이다. 그런데 막상 "내부적으로 뭘 하는 거야?"라고 물으면 선뜻 답하기 어려웠다. 이번 주 직접 mycontainer_exec를 만들어보면서 정리한 내용을 적어본다. 왜 새 컨테이너를 하나 더 띄우면 안 되는가가장 먼저 든 의문은 이거였다. "그냥 clone()으로 새 프로세스를 하나 더 만들면 안 되나?"안 된다. clone()으로 완전히 새로운 namespace를 만들면, 그건 새 컨테이너를 하나 더 만드는 것이지 기존 컨테이너에 들어가는 게 아니다. 예를 들어 컨테이너 안에서 nginx가 어떤 파일을 서빙하고 있을 때, 새 namespace를 만들어서..