eBPF / bpf2go - BTF Style Maps 정의 구문과 데이터 정렬 문제
libbpf에서는 BPF map 정의가 바뀌었다고 했는데요,
eBPF의 2가지 방식 - libbcc와 libbpf(CO-RE) 4. BPF maps
; https://www.sysnet.pe.kr/2/0/13801#4
아래의 공식 문서에서도 "legacy"와 "BTF style"로 나눠서 설명하고 있습니다.
eBPF Docs - Maps
; https://docs.ebpf.io/linux/concepts/maps/
legacy는 슬슬 지원하지 않는 듯하니, 이번 글에서는 BTF Style에 대해서만 다뤄볼 텐데요, 기본적인 정의는 다음과 같이 할 수 있습니다.
struct my_value { int x, y, z; };
struct {
__uint(type, BPF_MAP_TYPE_ARRAY);
__type(key, int);
__type(value, struct my_value);
__uint(max_entries, 16);
} icmpcnt __attribute__((section(".maps"), used)); // == SEC(".maps");
낯설어 보이는 __uint, __type, __array, __ulong 등으로 인해 C 언어의 struct 구문에서 약간 빗나간 것처럼 보일 수도 있지만 문서에서 설명하듯이 이들은 매크로 정의에 불과합니다.
#define __uint(name, val) int (*name)[val]
#define __type(name, val) typeof(val) *name
#define __array(name, val) typeof(val) *name[]
#define __ulong(name, val) enum { ___bpf_concat(__unique_value, __COUNTER__) = val } name
그래서 결국, 위와 같은 코드를 컴파일하면 다음과 같이 구조체 정의로 바뀝니다.
/* BPF_MAP_TYPE_ARRAY 정의
$ cat /usr/include/linux/bpf.h | grep -B 3 BPF_MAP_TYPE_ARRAY,
enum bpf_map_type {
BPF_MAP_TYPE_UNSPEC,
BPF_MAP_TYPE_HASH,
BPF_MAP_TYPE_ARRAY,
*/
/*
// gcc - 매크로를 확장한 코드를 출력
$ gcc -E test.c
*/
/*
// Visual C++ - 매크로를 확장한 코드 파일(test.i)을 산출
C:\temp> cl test.c /std:clatest /P
*/
struct my_value { int x, y, z; };
struct {
int (*type)[BPF_MAP_TYPE_ARRAY];
int *key;
struct my_value *value;
int (*max_entries)[16];
} icmpcnt __attribute__((section(".maps"), used));
C 코딩을 하면서 구조체를 "struct { ... } name;" 형태(
anonymous struct)로 쓰는 경우는 잘 없는데요, 왜냐하면 이런 식으로 쓰면 type 이름이 없이 곧바로 변수를 정의하는 것과 같기 때문입니다.
그래서, 코드 내에서 저렇게 선언된 전역 변수를 사용할 수는 있지만,
bpf_map_update_elem(&icmpcnt, ..., ..., BPF_ANY);
임의로 저 타입의 변수를 (
typeof가 추가된 C23 표준 전에는) 만들 수는 없습니다.
대충 정의가 눈에 들어왔으면, 이제 bpf2go와 연동해 볼까요?
우선, 간단하게 key/value가 모두 primitive type인 경우를 살펴보겠습니다.
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__type(key, __u32);
__type(value, __u32);
__uint(max_entries, 10000);
} my_u32_key_value_map SEC(".maps");
// ... eBPF 함수 ...
{
__u32 key = 1000;
__u32 value = 2000;
bpf_map_update_elem(&my_u32_key_value_map, &key, &value, BPF_ANY);
}
위와 같이 정의한 map의 모든 데이터를 go 언어 측에서 조회하려면 map에 정의한 key, value 타입에 맞춰 주기만 하면 됩니다.
iter := bpfObj.MyU64KeyValueMap.Iterate()
var (
key uint32
value uint32
)
for iter.Next(&key, &value) {
log.Printf("key: %v, value: %v\n", key, value)
}
그렇다면, key의 타입을 다중 필드를 가진 타입으로 확장하면 어떨까요?
struct key128 {
__u64 key1;
__u64 key2;
};
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__type(key, struct key128);
__type(value, __u32);
__uint(max_entries, 10000);
} my_hash_key128_map SEC(".maps");
바뀐 key의 구조대로 go 언어 측에서도 타입을 맞춰주고 실행할 수 있습니다.
type Key128 struct {
key1 uint64
key2 uint64
}
var (
key Key128
value uint32
)
idx := 0
for iter.Next(&key, &value) {
log.Printf("[%v], key: %v, value: %v\n", idx, key, value)
idx++
}
어렵지 않죠? ^^
다중 필드를 가진 구조체의 경우 한 가지 유의해야 할 점이 있는데요, eBPF는 C 언어이기 때문에 구조체의 크기도 CPU word 단위로 정렬되는 것이 기본 동작입니다.
즉, key 구조체를 다음과 같이 정의했다면,
struct key96 {
__u64 key1; // 8바이트
__u32 key2; // 4바이트
};
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__type(key, struct key96);
__type(value, __u32);
__uint(max_entries, 10000);
} my_hash_key96_map SEC(".maps");
표면상으로는 12바이트를 점유하지만, 실제로는 16바이트로 다뤄집니다.
struct key96 e1 = { 50, 51 };
__u32 size1 = sizeof(e1);
bpf_printk("sizeof(key96) %d", size1); // 출력 결과: sizeof(key96) 16
이런 상태에서 Go 언어 측에서 다음과 같은 key 정의로 접근하면,
type Key96 struct {
Key1 uint64
Key2 uint32
}
var (
key Key96
value uint32
)
iter := bpfObj.MyHashKey96Map.Iterate()
idx := 0
for iter.Next(&key, &value) {
log.Printf("[%v], key: %v, value: %v\n", idx, key, value)
idx++
}
err := iter.Err()
if err != nil {
log.Printf("failed to iterate: %v\n", err) // 출력 결과: unmarshaling *main.Key96 doesn't consume all data
}
저렇게 "unmarshaling *main.Key96 doesn't consume all data"라는 오류 메시지가 출력됩니다. 따라서 이런 경우에는 오히려 key 정의를 모두 64비트로 맞춰줘야 합니다.
type Key96 struct {
Key1 uint64
Key2 uint64
}
또는, eBPF 측의 구조체 정의를 아예 packed로 정의해 정렬 규칙을 무시하도록 만드는 것도 방법입니다.
struct packedKey96 {
__u64 key1;
__u32 key2;
} __attribute__((packed)); // Visual C++의 경우 pragma 지시자
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__type(key, struct packedKey96);
__type(value, __u32);
__uint(max_entries, 10000);
} my_hash_key96_map SEC(".maps");
이렇게 바꿔주면 Go 언어 측에서도 동일하게 (uint64, uint32)의 키로 접근할 수 있습니다.
참고로, map 정의 시 key, value가 아닌 key_size, value_size를 사용하는 것도 가능합니다. 이렇게 하는 경우에는 __type 매크로가 아닌 __uint 매크로를 사용해야 한다는 것에 유의해야 합니다.
즉, 다음의 2가지 map은 완전히 동일한 구조의 맵을 정의합니다.
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__type(key, struct key128);
__type(value, __u32);
__uint(max_entries, 10000);
} my_hash_key128_map SEC(".maps");
// __type ==> __uint
// 필드명은 key, value를 각각 key_size, value_size로 변경
// 두 번째 인자에는 타입명 대신 sizeof(...), 또는 직접 바이트 크기를 명시
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__uint(key_size, sizeof(struct key128)); // 또는, __uint(key_size, 16);
__uint(value_size, sizeof(__u32)); // 또는, __uint(value_size, 4);
__uint(max_entries, 10000);
} my_hash_key128_map SEC(".maps");
만약 저걸 혼동해서 __type을 그대로 남겨두고 sizeof(...)를 사용한다거나 하면,
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__type(key, sizeof(struct key128));
__type(value, __u32);
__uint(max_entries, 10000);
} my_hash_key128_map SEC(".maps");
어떻게 섞었느냐에 따라 eBPF 프로그램을 로드하는 시점에 이런 식의 오류가 발생하거나,
invalid argument: invalid indirect access to stack R2 off=-24 size=64 (60 line(s) omitted)
로딩은 되지만 iter.Next 시에 "unexpected EOF" 오류가 발생할 수 있습니다.
만약 iter.Next에서 이런 오류가 발생한다면?
iter.Next(&key, &value)
// panic: reflect: reflect.Value.SetUint using value obtained using unexported field
goroutine 18 [running]:
reflect.flag.mustBeAssignableSlow(0x6bce3645f26bc00f?)
/snap/go/10853/src/reflect/value.go:254 +0xb4
reflect.flag.mustBeAssignable(...)
/snap/go/10853/src/reflect/value.go:244
reflect.Value.SetUint({0x57d0a0?, 0xc0002800a0?, 0x733040?}, 0x32)
/snap/go/10853/src/reflect/value.go:2181 +0x45
encoding/binary.(*decoder).value(0xc00015fcf8, {0x57d0a0?, 0xc0002800a0?, 0x4?})
/snap/go/10853/src/encoding/binary/binary.go:894 +0x32c
encoding/binary.(*decoder).value(0xc00015fcf8, {0x595b60?, 0xc0002800a0?, 0xc?})
/snap/go/10853/src/encoding/binary/binary.go:863 +0x7e5
encoding/binary.Read({0x5fcbc0, 0xc00028e060}, {0x5fe310, 0x732140}, {0x575560, 0xc0002800a0})
/snap/go/10853/src/encoding/binary/binary.go:289 +0x385
github.com/cilium/ebpf/internal/sysenc.Unmarshal({0x575560, 0xc0002800a0}, {0xc0002800c0, 0x10, 0x10})
/home/testusr/go/pkg/mod/github.com/cilium/ebpf@v0.16.0/internal/sysenc/marshal.go:108 +0x2e5
github.com/cilium/ebpf.(*MapIterator).Next(0xc00015fed0, {0x575560, 0xc0002800a0}, {0x577920, 0xc0002800b0})
/home/testusr/go/pkg/mod/github.com/cilium/ebpf@v0.16.0/map.go:1621 +0x2dd
main.IterMyHashMap({{0xc0001223c0, 0xc000122400}, {0xc000144460, 0xc0001444b0, 0xc000144500, 0xc000144410, 0xc000144550, 0xc0001445a0, 0xc0001445f0, 0xc000144640, ...}})
/home/testusr/ebpf_sample/main.go:149 +0x311
created by main.main in goroutine 1
/home/testusr/ebpf_sample/main.go:132 +0x698
혹시 key나 value가 구조체가 아닌지 확인하고, 만약 구조체라면 필드를 소문자로 한 것은 아닌지 확인해 보세요. ^^;
type Key128 struct {
key1 uint64
key2 uint64
}
iter.Next는 내부적으로 reflect 패키지로 역직렬화를 하는데, 이 과정에서 구조체의 변수가 소문자로 시작한다면 직렬화 과정에서 제외(unexported field)시키므로 iter.Next에서 오류가 발생합니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]