eBPF - BPF_PROG_TYPE_CGROUP_SOCK 유형에서 정상 동작하지 않는 BPF_CORE_READ (2)
지난 글에서,
eBPF - BPF_PROG_TYPE_CGROUP_SOCK 유형에서 정상 동작하지 않는 BPF_CORE_READ
; https://www.sysnet.pe.kr/2/0/13979
eBPF의 BPF_PROG_TYPE_CGROUP_SOCK 유형에서, BTF 구조체의 필드를 직접 접근한 경우에만 정상 동작하는 현상을 설명했는데요, 실제로 몇몇 유형의 프로그램 유형에서는 이것이 허용된다고 합니다.
BTF-enabled BPF program types with direct memory reads
; https://nakryiko.com/posts/bpf-core-reference-guide/#btf-enabled-bpf-program-types-with-direct-memory-reads
위의 글에 따르면 다음의 4가지 BPF program type은,
- BTF-enabled raw tracepoint (SEC("tp_btf/...") in libbpf lingo);
- fentry/fexit/fmod_ret BPF programs;
- BPF LSM programs;
- probably some more but I'm too lazy to go and check.
"BTF-enabled" 취급을 받게 되므로 해당 프로그램 내에서의 직접 접근인 경우에도 BPF verifier가 이를 인지해 bpf_core_read/bpf_probe_read_kernel 함수를 사용하지 않아도 된다는데요.
BPF_PROG_TYPE_CGROUP_SOCK 유형은 위의 1~3번에 속하지는 않지만, 어쩌면 4번에 속할 수는 있으니 구조체의 필드를 직접 접근하는 것이 호환성을 떨어뜨리지는 않을 수 있습니다. 단지 문제가 있다면, 도대체 "BTF-enabled"에 해당하는 BPF Program type에 대한 정보를 검색으로는 찾을 수가 없다는 점입니다. AI는 무슨 자신감이 넘치는지 "Yes, BPF_PROG_TYPE_CGROUP_SOCK is a BTF-enabled BPF program type."라고 답변하는데... 이것 참 곧이곧대로 믿을 수가 없군요. (혹시 관련해서 공식 문서를 알고 계신 분은 덧글로 알려주시면 감사하겠습니다. ^^)
그렇다면, 다시 BPF_PROG_TYPE_CGROUP_SOCK 유형에 대해 자세하게 알아볼까요? ^^
Program type BPF_PROG_TYPE_CGROUP_SOCK
; https://docs.ebpf.io/linux/program-type/BPF_PROG_TYPE_CGROUP_SOCK/#context
- cgroup/sock_create
- cgroup/sock_release
- cgroup/post_bind4
- cgroup/post_bind6
이와 함께 Program Type은 다르지만
BPF_PROG_TYPE_CGROUP_SOCK_ADDR 유형에 "cgroup/bind4", "cgroup/bind6" 단계도 있습니다. 이벤트 순서로 보면 "bind4/6"가 먼저 실행되고, 이후 "post_bind4/6" 단계로 넘어갑니다. (한 마디로, pre/post 관계라고 보면 됩니다.)
개별 프로그램을 Socket API와 비교해 보면 각각 다음과 같이 대응하는 것을 알 수 있습니다.
- sock_create ==> socket()
- sock_release ==> close()
- post_bind4 / post_bind6 ==> bind()
또한, 공통으로 bpf_sock 구조체를 받아들이는데요, (BPF_PROG_TYPE_CGROUP_SOCK_ADDR 유형은 bpf_sock_addr 구조체를 받습니다.)
// https://codebrowser.dev/linux/include/linux/bpf.h.html#bpf_sock
// cat /usr/include/linux/bpf.h | grep -A 17 "struct bpf_sock {"
// cat vmlinux.h | grep -A 15 "struct bpf_sock {"
struct bpf_sock {
__u32 bound_dev_if;
__u32 family;
__u32 type;
__u32 protocol;
__u32 mark;
__u32 priority;
/* IP address also allows 1 and 2 bytes access */
__u32 src_ip4;
__u32 src_ip6[4];
__u32 src_port; /* host byte order */
__be16 dst_port; /* network byte order */
__u16 :16; /* zero padding */
__u32 dst_ip4;
__u32 dst_ip6[4];
__u32 state;
__s32 rx_queue_mapping;
};
여기서 주의할 것은, sock_create/release, post_bind4/bind6 단계마다 내부 필드에 접근할 수 있는 것이 정해져 있다는 점입니다. 가령, socket(...) 함수와 대응하는 sock_create 단계에서는 아직 연결은 안 된 상태이기 때문에 src_ip4, src_port 등의 정보는 알 수 없는데요, 재미있게도 단순히 참조할 가치가 없는 정도가 아니라, 아예 참조를 하면, 심지어 참조를 하는 코드조차도 있으면 BPF verifier가 오류를 발생시킵니다.
예를 들어, sock_create 단계에서 src_port 필드에 접근하려고 하면,
__u32 sock_src_port = ctx->src_port;
bpf2go 빌드 단계에서는 정상으로 넘어가지만 BPF 프로그램을 Load하는 단계에서는 아래와 같은 오류가 발생합니다.
permission denied: 11: (61) r7 = *(u32 *)(r6 +44): invalid bpf_context access off=44 size=4 (20 line(s) omitted)
하지만, 이런 경우조차도 BPF_CORE_READ 매크로나 bpf_core_read 함수를 사용하면,
__u32 sock_src_port = BPF_CORE_READ(ctx, src_port);
BPF 로딩 단계에서 오류가 발생하지는 않지만, 실행 시 읽히는 값은 0으로 나옵니다.
참고로, 일부 값은 쓰기도 가능한데요, 얼마나 유용할지는 모르겠지만 현재는 오직 sock_create / sock_relase 단계에서 bound_dev_if, mark, priority 3개의 필드에 대해 변경이 가능합니다.
또한
src_ip4와 dst_ip4의 경우에는 BPF_CGROUP_INET4_POST_BIND에서만 읽기가 가능하고 BPF_CGROUP_INET6_POST_BIND 단계에서는 접근 코드 자체가 있으면 (실행이 아닌) 로딩 단계에서 이런 오류가 발생합니다.
// src_ip4 접근 코드가 있는 경우
permission denied: 37: (61) r1 = *(u32 *)(r6 +24): invalid bpf_context access off=24 size=4 (52 line(s) omitted)
// dst_ip4 접근 코드가 있는 경우
permission denied: dereference of modified ctx ptr R1 off=52 disallowed (58 line(s) omitted)
왜 2개의 오류 메시지가 다른지는 잘 모르겠지만, 어쨌든 테스트한 결과로는 저렇게 나왔습니다. 실은, 저게 문서상으로는 틀린 정보를 담고 있었는데, 제가 직접 테스트하면서 알게 돼 문서에 반영을 요청했었습니다. ^^
Update BPF_PROG_TYPE_CGROUP_SOCK.md #206
; https://github.com/isovalent/ebpf-docs/pull/206
꽤나 빠르게 처리해서 놀랐다는. ^^
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]