어린이를 위한 BPF XNUMX부: 확장된 BPF

태초에 BPF라는 기술이 있었습니다. 우리는 그녀를 바라보았다 이전, 이 시리즈의 구약성서 기사. 2013년에는 Alexei Starovoitov와 Daniel Borkman의 노력을 통해 최신 64비트 시스템에 최적화된 향상된 버전이 개발되어 Linux 커널에 포함되었습니다. 이 새로운 기술은 간단히 Internal BPF라고 불렸다가 Extended BPF로 이름이 바뀌었고 몇 년이 지난 지금은 모두가 간단히 BPF라고 부릅니다.

대략적으로 말하면 BPF를 사용하면 Linux 커널 공간에서 임의의 사용자 제공 코드를 실행할 수 있으며 새 아키텍처는 매우 성공적이어서 모든 애플리케이션을 설명하려면 XNUMX개의 기사가 더 필요할 것입니다. (아래 성능 코드에서 볼 수 있듯이 개발자들이 유일하게 잘 못한 것은 괜찮은 로고를 만드는 것이었습니다.)

이 기사에서는 BPF 가상 머신의 구조, BPF 작업을 위한 커널 인터페이스, 개발 도구 및 기존 기능에 대한 간략하고 간단한 개요를 설명합니다. BPF의 실제 적용에 대한 더 깊은 연구를 위해 미래에 필요한 모든 것입니다.

기사 요약

BPF 아키텍처 소개. 먼저 BPF 아키텍처를 조감도로 살펴보고 주요 구성 요소의 개요를 살펴보겠습니다.

BPF 가상 머신의 레지스터 및 명령 시스템입니다. 이미 아키텍처 전체에 대한 아이디어를 갖고 있으므로 BPF 가상 머신의 구조를 설명하겠습니다.

BPF 객체의 수명 주기, bpffs 파일 시스템. 이 섹션에서는 BPF 객체(프로그램 및 맵)의 수명 주기를 자세히 살펴보겠습니다.

bpf 시스템 호출을 사용하여 객체를 관리합니다. 이미 구축된 시스템에 대한 어느 정도 이해를 바탕으로 마지막으로 특수 시스템 호출을 사용하여 사용자 공간에서 객체를 생성하고 조작하는 방법을 살펴보겠습니다. bpf(2).

Пишем программы BPF с помощью libbpf. 물론 시스템 호출을 사용하여 프로그램을 작성할 수도 있습니다. 하지만 어렵습니다. 보다 현실적인 시나리오를 위해 핵 프로그래머는 라이브러리를 개발했습니다. libbpf. 후속 예제에서 사용할 기본 BPF 애플리케이션 뼈대를 만듭니다.

커널 도우미. 여기서는 BPF 프로그램이 커널 도우미 기능(맵과 함께 기본 BPF에 비해 새로운 BPF의 기능을 근본적으로 확장하는 도구)에 액세스할 수 있는 방법을 알아봅니다.

BPF 프로그램에서 지도에 액세스합니다. 이 시점에서 우리는 지도를 사용하는 프로그램을 만드는 방법을 정확히 이해할 만큼 충분히 알게 될 것입니다. 그리고 위대하고 막강한 검증자에 대해서도 잠깐 살펴보겠습니다.

개발 도구. 실험에 필요한 유틸리티와 커널을 조립하는 방법에 대한 도움말 섹션입니다.

결론. 여기까지 읽은 사람들은 기사 끝부분에서 동기를 부여하는 단어와 다음 기사에서 일어날 일에 대한 간략한 설명을 발견하게 될 것입니다. 또한 계속되는 학습을 기다릴 의지나 능력이 없는 사람들을 위해 자율 학습을 위한 여러 링크도 나열할 것입니다.

BPF 아키텍처 소개

BPF 아키텍처를 고려하기 전에 마지막으로 (오) 다음을 참조하겠습니다. 클래식 BPF는 RISC 머신의 출현에 대응하여 개발되었으며 효율적인 패킷 필터링 문제를 해결했습니다. 이 아키텍처는 매우 성공적인 것으로 판명되어 XNUMX년대 Berkeley UNIX에서 탄생하여 대부분의 기존 운영 체제로 포팅되었으며 미친 XNUMX년대까지 살아남았으며 여전히 새로운 응용 프로그램을 찾고 있습니다.

새로운 BPF는 64비트 머신, 클라우드 서비스의 편재성 및 SDN 생성을 위한 도구에 대한 필요성 증가에 대한 대응으로 개발되었습니다(Software-d정교한 n에트워킹). 기존 BPF의 개선된 대체품으로 커널 네트워크 엔지니어에 의해 개발된 새로운 BPF는 문자 그대로 XNUMX개월 후에 Linux 시스템을 추적하는 어려운 작업에서 응용 프로그램을 발견했으며 이제 등장한 지 XNUMX년이 지났으므로 다음 기사 전체가 필요합니다. 다양한 종류의 프로그램을 나열해 보세요.

재밌는 사진

기본적으로 BPF는 보안을 손상시키지 않고 커널 공간에서 "임의" 코드를 실행할 수 있게 해주는 샌드박스 가상 머신입니다. BPF 프로그램은 사용자 공간에서 생성되고 커널에 로드되며 일부 이벤트 소스에 연결됩니다. 예를 들어, 네트워크 인터페이스로의 패킷 전달, 일부 커널 기능 실행 등이 이벤트가 될 수 있습니다. 패키지의 경우 BPF 프로그램은 패키지의 데이터 및 메타데이터에 액세스할 수 있습니다(프로그램 유형에 따라 읽기 및 쓰기를 위해). 커널 함수를 실행하는 경우 커널 메모리에 대한 포인터 등을 포함한 함수

이 과정을 자세히 살펴보겠습니다. 우선, 어셈블러로 작성된 프로그램인 클래식 BPF와의 첫 번째 차이점에 대해 이야기해 보겠습니다. 새 버전에서는 프로그램을 고급 언어(주로 C)로 작성할 수 있도록 아키텍처가 확장되었습니다. 이를 위해 BPF 아키텍처용 바이트코드를 생성할 수 있는 llvm용 백엔드가 개발되었습니다.

BPF 아키텍처는 부분적으로 최신 머신에서 효율적으로 실행되도록 설계되었습니다. 실제로 이 작업을 수행하기 위해 커널에 로드된 BPF 바이트코드는 JIT 컴파일러(Just In T임). 다음으로, 클래식 BPF에서 프로그램은 단일 시스템 호출의 맥락에서 커널에 로드되고 이벤트 소스에 원자적으로 연결되었습니다. 새로운 아키텍처에서는 이 작업이 두 단계로 진행됩니다. 첫째, 시스템 호출을 사용하여 코드가 커널에 로드됩니다. bpf(2)그런 다음 나중에 프로그램 유형에 따라 달라지는 다른 메커니즘을 통해 프로그램이 이벤트 소스에 연결됩니다.

여기서 독자는 질문을 가질 수 있습니다. 가능했습니까? 그러한 코드의 실행 안전성은 어떻게 보장됩니까? verifier라고 하는 BPF 프로그램을 로드하는 단계에서 실행 안전성이 보장됩니다(영어에서는 이 단계를 verifier라고 하며 계속해서 영어 단어를 사용하겠습니다).

Verifier는 프로그램이 커널의 정상적인 작동을 방해하지 않는지 확인하는 정적 분석기입니다. 이는 프로그램이 시스템 작동을 방해할 수 없다는 의미는 아닙니다. BPF 프로그램은 유형에 따라 커널 메모리 섹션을 읽고 다시 쓸 수 있고, 함수 값을 반환하고, 다듬고, 추가하고, 다시 쓸 수 있습니다. 네트워크 패킷을 전달할 수도 있습니다. Verifier는 BPF 프로그램을 실행하면 커널이 충돌하지 않으며 규칙에 따라 쓰기 액세스 권한이 있는 프로그램(예: 나가는 패킷의 데이터)이 패킷 외부의 커널 메모리를 덮어쓸 수 없음을 보장합니다. BPF의 다른 모든 구성 요소에 대해 알게 된 후 해당 섹션에서 검증자를 좀 더 자세히 살펴보겠습니다.

그럼 우리는 지금까지 무엇을 배웠나요? 사용자는 C로 프로그램을 작성하고 시스템 호출을 사용하여 이를 커널에 로드합니다. bpf(2), 검증자에 의해 확인되고 기본 바이트코드로 변환됩니다. 그런 다음 동일하거나 다른 사용자가 프로그램을 이벤트 소스에 연결하고 실행을 시작합니다. 여러 가지 이유로 부팅과 연결을 분리해야 합니다. 첫째, 검증 프로그램을 실행하는 것은 상대적으로 비용이 많이 들고 동일한 프로그램을 여러 번 다운로드함으로써 컴퓨터 시간을 낭비합니다. 둘째, 프로그램이 연결되는 정확한 방식은 유형에 따라 다르며, XNUMX년 전에 개발된 하나의 "유니버설" 인터페이스는 새로운 유형의 프로그램에는 적합하지 않을 수 있습니다. (지금은 아키텍처가 성숙해지고 있지만, 이 인터페이스를 레벨에서 통합하려는 아이디어가 있습니다. libbpf.)

주의 깊은 독자라면 우리가 아직 그림 작업을 마치지 않았다는 것을 알아차릴 수도 있을 것입니다. 실제로 위의 모든 내용은 BPF가 기본 BPF에 비해 그림을 근본적으로 바꾸는 이유를 설명하지 않습니다. 적용 범위를 크게 확장하는 두 가지 혁신은 공유 메모리와 커널 도우미 기능을 사용하는 기능입니다. BPF에서 공유 메모리는 소위 맵(특정 API를 사용한 공유 데이터 구조)을 사용하여 구현됩니다. 아마도 처음으로 등장한 지도 유형이 해시 테이블이었기 때문에 이 이름을 갖게 된 것 같습니다. 그런 다음 배열, 로컬(CPU별) 해시 테이블 및 로컬 배열, 검색 트리, BPF 프로그램에 대한 포인터가 포함된 맵 등이 나타났습니다. 이제 우리에게 흥미로운 점은 BPF 프로그램이 이제 호출 간에 상태를 유지하고 이를 다른 프로그램 및 사용자 공간과 공유할 수 있다는 것입니다.

맵은 시스템 호출을 사용하여 사용자 프로세스에서 액세스됩니다. bpf(2), 그리고 도우미 함수를 사용하여 커널에서 실행되는 BPF 프로그램에서. 더욱이, 맵 작업뿐만 아니라 다른 커널 기능에 액세스하기 위한 헬퍼도 존재합니다. 예를 들어 BPF 프로그램은 도우미 함수를 사용하여 패킷을 다른 인터페이스로 전달하고, 성능 이벤트를 생성하고, 커널 구조에 액세스하는 등의 작업을 수행할 수 있습니다.

요약하자면, BPF는 검증자 테스트를 거친 임의의 사용자 코드를 커널 공간에 로드하는 기능을 제공합니다. 이 코드는 호출 간 상태를 저장하고 사용자 공간과 데이터를 교환할 수 있으며 이러한 유형의 프로그램에서 허용하는 커널 하위 시스템에 액세스할 수도 있습니다.

이는 커널 모듈이 제공하는 기능과 이미 유사하며 BPF에는 몇 가지 장점이 있습니다(물론 시스템 추적과 같은 유사한 애플리케이션만 비교할 수 있습니다. BPF를 사용하여 임의의 드라이버를 작성할 수는 없습니다). 낮은 진입 임계값(BPF를 사용하는 일부 유틸리티는 사용자에게 커널 프로그래밍 기술 또는 일반적인 프로그래밍 기술이 필요하지 않음), 런타임 안전성(작성 시 시스템을 손상시키지 않은 사람들을 위해 의견에 손을 들어주세요)을 확인할 수 있습니다. 또는 테스트 모듈), 원자성 - 모듈을 다시 로드할 때 가동 중지 시간이 있으며 BPF 하위 시스템은 이벤트가 누락되지 않도록 보장합니다(공평하게 말하면 모든 유형의 BPF 프로그램에 해당되는 것은 아닙니다).

이러한 기능의 존재로 인해 BPF는 커널 확장을 위한 보편적인 도구가 되었으며 이는 실제로 확인되었습니다. 점점 더 많은 새로운 유형의 프로그램이 BPF에 추가되고 점점 더 많은 대기업이 전투 서버에서 BPF를 24×7 사용하는 등 점점 더 많아지고 있습니다. 스타트업은 BPF 기반 솔루션을 기반으로 비즈니스를 구축합니다. BPF는 DDoS 공격 방지, SDN 생성(예: 쿠버네티스용 네트워크 구현), 주요 시스템 추적 도구 및 통계 수집기, 침입 탐지 시스템 및 샌드박스 시스템 등 모든 곳에서 사용됩니다.

여기서 기사의 개요 부분을 마무리하고 가상 머신과 BPF 생태계를 더 자세히 살펴보겠습니다.

여담: 유틸리티

다음 섹션의 예제를 실행하려면 최소한 여러 가지 유틸리티가 필요할 수 있습니다. llvm/clang bpf 지원 및 bpftool. 섹션 개발 도구 유틸리티와 커널을 조립하는 방법에 대한 지침을 읽을 수 있습니다. 이 섹션은 우리 발표의 조화를 방해하지 않도록 아래에 배치됩니다.

BPF 가상 머신 레지스터 및 명령 시스템

BPF의 아키텍처와 명령 시스템은 프로그램이 C 언어로 작성되고 커널에 로드된 후 네이티브 코드로 변환된다는 사실을 고려하여 개발되었습니다. 따라서 레지스터 수와 명령 세트는 수학적 의미에서 현대 기계 기능의 교차점을 고려하여 선택되었습니다. 또한 프로그램에는 다양한 제한이 적용되었습니다. 예를 들어 최근까지 루프와 서브루틴을 작성할 수 없었고 명령 수가 4096개로 제한되었습니다(현재 권한 있는 프로그램은 최대 백만 개의 명령을 로드할 수 있습니다).

BPF에는 사용자가 액세스할 수 있는 64개의 XNUMX비트 레지스터가 있습니다. r0-r10 그리고 프로그램 카운터. 등록하다 r10 프레임 포인터를 포함하며 읽기 전용입니다. 프로그램은 런타임 시 512바이트 스택에 액세스할 수 있으며 맵 형태의 무제한 공유 메모리에 액세스할 수 있습니다.

BPF 프로그램은 특정 프로그램 유형 커널 도우미 세트와 최근에는 일반 기능을 실행할 수 있습니다. 호출된 각 함수는 레지스터에 전달된 최대 XNUMX개의 인수를 사용할 수 있습니다. r1-r5, 반환 값은 다음으로 전달됩니다. r0. 함수에서 반환된 후 레지스터의 내용이 보장됩니다. r6-r9 변경되지 않습니다.

효율적인 프로그램 번역을 위해 레지스터 r0-r11 지원되는 모든 아키텍처는 현재 아키텍처의 ABI 기능을 고려하여 실제 레지스터에 고유하게 매핑됩니다. 예를 들어, x86_64 레지스터 r1-r5함수 매개변수를 전달하는 데 사용되는 는 다음에 표시됩니다. rdi, rsi, rdx, rcx, r8, 매개변수를 함수에 전달하는 데 사용됩니다. x86_64. 예를 들어 왼쪽의 코드는 다음과 같이 오른쪽의 코드로 변환됩니다.

1:  (b7) r1 = 1                    mov    $0x1,%rdi
2:  (b7) r2 = 2                    mov    $0x2,%rsi
3:  (b7) r3 = 3                    mov    $0x3,%rdx
4:  (b7) r4 = 4                    mov    $0x4,%rcx
5:  (b7) r5 = 5                    mov    $0x5,%r8
6:  (85) call pc+1                 callq  0x0000000000001ee8

레지스터 r0 프로그램 실행 결과를 반환하는 데에도 사용되며 레지스터에서 r1 프로그램에는 컨텍스트에 대한 포인터가 전달됩니다. 프로그램 유형에 따라 이는 예를 들어 구조일 수 있습니다. struct xdp_md (XDP의 경우) 또는 구조 struct __sk_buff (다른 네트워크 프로그램의 경우) 또는 구조 struct pt_regs (다양한 유형의 추적 프로그램용) 등

그래서 우리는 레지스터 세트, 커널 도우미, 스택, 컨텍스트 포인터 및 맵 형태의 공유 메모리를 갖게 되었습니다. 여행에서 이 모든 것이 꼭 필요한 것은 아니지만...

계속해서 설명하고 이러한 개체를 사용하는 명령 시스템에 대해 이야기해 보겠습니다. 모두 (거의 모든) BPF 명령어의 크기는 64비트로 고정되어 있습니다. 64비트 Big Endian 시스템에서 한 명령어를 보면 다음과 같은 내용을 볼 수 있습니다.

여기에 Code - 이것은 명령어의 인코딩입니다. Dst/Src 는 각각 수신자와 소스의 인코딩입니다. Off - 16비트 부호 있는 들여쓰기 및 Imm 일부 명령어에 사용되는 32비트 부호 있는 정수입니다(cBPF 상수 K와 유사). 부호화 Code 두 가지 유형 중 하나가 있습니다.

명령어 클래스 0, 1, 2, 3은 메모리 작업을 위한 명령을 정의합니다. 그들 부르다, BPF_LD, BPF_LDX, BPF_ST, BPF_STX, 각각. 4, 7급 (BPF_ALU, BPF_ALU64)은 ALU 명령어 세트를 구성합니다. 5, 6급 (BPF_JMP, BPF_JMP32) 점프 명령이 포함되어 있습니다.

BPF 명령어 시스템을 연구하기 위한 추가 계획은 다음과 같습니다. 모든 명령어와 해당 매개변수를 꼼꼼하게 나열하는 대신 이 섹션의 몇 가지 예를 살펴보고 명령어가 실제로 어떻게 작동하고 어떻게 작동하는지 명확하게 알 수 있습니다. BPF용 바이너리 파일을 수동으로 분해합니다. 기사 뒷부분에서 자료를 통합하기 위해 Verifier, JIT 컴파일러, 클래식 BPF 번역, 맵 연구, 함수 호출 등에 관한 섹션에서 개별 지침도 만날 것입니다.

개별 지침에 대해 이야기할 때 핵심 파일을 참조합니다. bpf.h и bpf_common.h, BPF 명령어의 숫자 코드를 정의합니다. 자체적으로 아키텍처를 연구하거나 바이너리를 구문 분석할 때 복잡한 순서로 정렬된 다음 소스에서 의미 체계를 찾을 수 있습니다. 비공식 eBPF 사양, BPF 및 XDP 참조 가이드, 명령어 세트, 문서/네트워킹/filter.txt 물론 Linux 소스 코드에는 검증자, JIT, BPF 인터프리터도 있습니다.

예: 머리 속에서 BPF를 분해하는 중

프로그램을 컴파일하는 예를 살펴보겠습니다. readelf-example.c 결과 바이너리를 살펴보세요. 원본 내용을 공개하겠습니다 readelf-example.c 아래에서는 바이너리 코드에서 논리를 복원한 후입니다.

$ clang -target bpf -c readelf-example.c -o readelf-example.o -O2
$ llvm-readelf -x .text readelf-example.o
Hex dump of section '.text':
0x00000000 b7000000 01000000 15010100 00000000 ................
0x00000010 b7000000 02000000 95000000 00000000 ................

출력의 첫 번째 열 readelf 들여쓰기이므로 프로그램은 네 가지 명령으로 구성됩니다.

Code Dst Src Off  Imm
b7   0   0   0000 01000000
15   0   1   0100 00000000
b7   0   0   0000 02000000
95   0   0   0000 00000000

명령 코드가 동일합니다. b7, 15, b7 и 95. 최하위 7비트는 명령어 클래스라는 점을 기억하세요. 우리의 경우 모든 명령어의 네 번째 비트가 비어 있으므로 명령어 클래스는 각각 5, 7, 5, 7입니다. 클래스 XNUMX은 BPF_ALU64, 그리고 5는 BPF_JMP. 두 클래스 모두 명령 형식은 동일하며(위 참조) 프로그램을 다음과 같이 다시 작성할 수 있습니다(동시에 나머지 열도 사람 형식으로 다시 작성합니다).

Op S  Class   Dst Src Off  Imm
b  0  ALU64   0   0   0    1
1  0  JMP     0   1   1    0
b  0  ALU64   0   0   0    2
9  0  JMP     0   0   0    0

운전 b 클래스 ALU64 -가요 BPF_MOV. 대상 레지스터에 값을 할당합니다. 비트가 설정된 경우 s (소스)이면 소스 레지스터에서 값을 가져오고, 우리의 경우처럼 설정되지 않은 경우 필드에서 값을 가져옵니다. Imm. 따라서 첫 번째와 세 번째 지침에서는 작업을 수행합니다. r0 = Imm. 또한 JMP 클래스 1 작업은 BPF_JEQ (같으면 점프). 우리의 경우 비트부터 S XNUMX이면 소스 레지스터의 값을 필드와 비교합니다. Imm. 값이 일치하면 다음으로 전환이 발생합니다. PC + Off어디에서 PC에는 평소와 같이 다음 명령어의 주소가 포함됩니다. 마지막으로 JMP 클래스 9 작업은 BPF_EXIT. 이 명령어는 프로그램을 종료하고 커널로 돌아갑니다. r0. 테이블에 새 열을 추가해 보겠습니다.

Op    S  Class   Dst Src Off  Imm    Disassm
MOV   0  ALU64   0   0   0    1      r0 = 1
JEQ   0  JMP     0   1   1    0      if (r1 == 0) goto pc+1
MOV   0  ALU64   0   0   0    2      r0 = 2
EXIT  0  JMP     0   0   0    0      exit

이를 보다 편리한 형식으로 다시 작성할 수 있습니다.

     r0 = 1
     if (r1 == 0) goto END
     r0 = 2
END:
     exit

기록부에 있는 내용을 기억한다면 r1 프로그램은 커널로부터 컨텍스트에 대한 포인터를 전달받고 레지스터에 r0 값이 커널에 반환되면 컨텍스트에 대한 포인터가 1이면 2을 반환하고 그렇지 않으면 - XNUMX를 반환한다는 것을 알 수 있습니다. 소스를 보고 우리가 옳은지 확인해 보겠습니다.

$ cat readelf-example.c
int foo(void *ctx)
{
        return ctx ? 2 : 1;
}

예, 의미 없는 프로그램입니다. 하지만 이는 단지 네 가지 간단한 지침으로 해석됩니다.

예외 예: 16바이트 명령어

앞에서 일부 명령어는 64비트 이상을 차지한다고 언급했습니다. 이는 예를 들어 지침에 적용됩니다. lddw (코드 = 0x18 = BPF_LD | BPF_DW | BPF_IMM) — 필드의 더블 워드를 레지스터에 로드합니다. Imm. 포인트이다 Imm 크기는 32이고 더블 워드는 64비트이므로 하나의 64비트 명령어로 64비트 즉시값을 레지스터에 로드하는 것은 작동하지 않습니다. 이를 위해 두 개의 인접한 명령어를 사용하여 필드에 64비트 값의 두 번째 부분을 저장합니다. Imm. 예:

$ cat x64.c
long foo(void *ctx)
{
        return 0x11223344aabbccdd;
}
$ clang -target bpf -c x64.c -o x64.o -O2
$ llvm-readelf -x .text x64.o
Hex dump of section '.text':
0x00000000 18000000 ddccbbaa 00000000 44332211 ............D3".
0x00000010 95000000 00000000                   ........

바이너리 프로그램에는 명령어가 두 개만 있습니다.

Binary                                 Disassm
18000000 ddccbbaa 00000000 44332211    r0 = Imm[0]|Imm[1]
95000000 00000000                      exit

우리는 지시를 가지고 다시 만날 것입니다 lddw, 재배치 및 지도 작업에 관해 이야기할 때

예: 표준 도구를 사용하여 BPF 분해

따라서 우리는 BPF 바이너리 코드를 읽는 방법을 배웠으며 필요한 경우 모든 명령어를 구문 분석할 준비가 되었습니다. 그러나 실제로는 다음과 같은 표준 도구를 사용하여 프로그램을 분해하는 것이 더 편리하고 빠르다고 말할 가치가 있습니다.

$ llvm-objdump -d x64.o

Disassembly of section .text:

0000000000000000 <foo>:
 0: 18 00 00 00 dd cc bb aa 00 00 00 00 44 33 22 11 r0 = 1234605617868164317 ll
 2: 95 00 00 00 00 00 00 00 exit

BPF 객체의 수명주기, bpffs 파일 시스템

(나는 이 하위 섹션에 설명된 세부 사항 중 일부를 처음으로 배웠습니다. 금식 알렉세이 스타로보이토프 BPF 블로그.)

BPF 객체(프로그램 및 맵)는 명령을 사용하여 사용자 공간에서 생성됩니다. BPF_PROG_LOAD и BPF_MAP_CREATE 시스템 호출 bpf(2), 다음 섹션에서 이것이 어떻게 발생하는지 정확히 설명하겠습니다. 이것은 커널 데이터 구조를 생성하고 각각에 대해 refcount (참조 횟수)가 XNUMX로 설정되고 해당 객체를 가리키는 파일 설명자가 사용자에게 반환됩니다. 손잡이를 닫은 후 refcount 개체는 XNUMX만큼 감소하고, XNUMX에 도달하면 개체가 파괴됩니다.

프로그램이 지도를 사용하는 경우 refcount 이 지도는 프로그램을 로드한 후 XNUMX씩 증가합니다. 즉, 해당 파일 설명자는 사용자 프로세스에서 닫힐 수 있지만 여전히 refcount XNUMX이 되지 않습니다:

프로그램을 성공적으로 로드한 후 일반적으로 이를 일종의 이벤트 생성기에 연결합니다. 예를 들어, 이를 네트워크 인터페이스에 배치하여 들어오는 패킷을 처리하거나 일부 인터페이스에 연결할 수 있습니다. tracepoint 핵심에. 이 시점에서 참조 카운터도 XNUMX씩 증가하고 로더 프로그램에서 파일 설명자를 닫을 수 있습니다.

이제 부트로더를 종료하면 어떻게 되나요? 이벤트 생성기(후크)의 유형에 따라 다릅니다. 모든 네트워크 후크는 로더가 완료된 후에 존재하게 되며, 이를 글로벌 후크라고 합니다. 예를 들어, 추적 프로그램은 이를 생성한 프로세스가 종료된 후에 해제됩니다(따라서 "로컬에서 프로세스로"라는 뜻으로 로컬이라고 함). 기술적으로 로컬 후크는 항상 사용자 공간에 해당 파일 설명자를 갖고 있으므로 프로세스가 닫힐 때 닫히지만 글로벌 후크는 그렇지 않습니다. 다음 그림에서는 빨간색 십자가를 사용하여 로컬 및 전역 후크의 경우 로더 프로그램 종료가 개체 수명에 어떤 영향을 미치는지 보여줍니다.

로컬 후크와 글로벌 후크가 구별되는 이유는 무엇입니까? 일부 유형의 네트워크 프로그램을 실행하는 것은 사용자 공간 없이도 가능합니다. 예를 들어 DDoS 보호를 상상해 보세요. 부트로더가 규칙을 작성하고 BPF 프로그램을 네트워크 인터페이스에 연결한 후 부트로더가 스스로 종료될 수 있습니다. 반면에 XNUMX분 만에 무릎을 꿇고 작성한 디버깅 추적 프로그램을 상상해 보십시오. 작업이 완료되면 시스템에 쓰레기가 남아 있지 않기를 원하며 로컬 후크가 이를 보장합니다.

반면에 커널의 추적점에 연결하여 수년에 걸쳐 통계를 수집한다고 가정해 보겠습니다. 이 경우 사용자 부분을 완료하고 때때로 통계로 돌아가고 싶을 것입니다. bpf 파일 시스템은 이러한 기회를 제공합니다. BPF 객체를 참조하는 파일 생성을 허용하는 메모리 내 전용 의사 파일 시스템입니다. refcount 사물. 그 후에는 로더가 종료될 수 있으며 생성된 개체는 계속 살아 있습니다.

BPF 객체를 참조하는 bpffs에 파일을 생성하는 것을 "고정"이라고 합니다(다음 구문에서와 같이 "프로세스는 BPF 프로그램 또는 맵을 고정할 수 있습니다"). BPF 객체에 대한 파일 객체를 생성하는 것은 로컬 객체의 수명을 연장할 뿐만 아니라 전역 객체의 유용성을 위해서도 의미가 있습니다. 전역 DDoS 보호 프로그램의 예로 돌아가서 통계를 볼 수 있기를 원합니다. 때때로.

BPF 파일 시스템은 일반적으로 다음 위치에 마운트됩니다. /sys/fs/bpf하지만 다음과 같이 로컬로 마운트할 수도 있습니다.

$ mkdir bpf-mountpoint
$ sudo mount -t bpf none bpf-mountpoint

파일 시스템 이름은 다음 명령을 사용하여 생성됩니다. BPF_OBJ_PIN BPF 시스템 호출. 설명을 위해 프로그램을 가져와서 컴파일하고 업로드한 후 핀으로 고정해 보겠습니다. bpffs. 우리 프로그램은 유용한 기능을 수행하지 않으며 예제를 재현할 수 있도록 코드만 제공합니다.

$ cat test.c
__attribute__((section("xdp"), used))
int test(void *ctx)
{
        return 0;
}

char _license[] __attribute__((section("license"), used)) = "GPL";

이 프로그램을 컴파일하고 파일 시스템의 로컬 복사본을 만들어 보겠습니다. bpffs:

$ clang -target bpf -c test.c -o test.o
$ mkdir bpf-mountpoint
$ sudo mount -t bpf none bpf-mountpoint

이제 유틸리티를 사용하여 프로그램을 다운로드해 보겠습니다. bpftool 그리고 그에 따른 시스템 호출을 살펴보세요 bpf(2) (strace 출력에서 ​​일부 관련 없는 행이 제거됨):

$ sudo strace -e bpf bpftool prog load ./test.o bpf-mountpoint/test
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, prog_name="test", ...}, 120) = 3
bpf(BPF_OBJ_PIN, {pathname="bpf-mountpoint/test", bpf_fd=3}, 120) = 0

여기에서는 다음을 사용하여 프로그램을 로드했습니다. BPF_PROG_LOAD, 커널로부터 파일 설명자를 받았습니다. 3 그리고 명령을 사용하여 BPF_OBJ_PIN 이 파일 설명자를 파일로 고정했습니다. "bpf-mountpoint/test". 그 후 부트로더 프로그램 bpftool 작업이 완료되었지만 프로그램을 네트워크 인터페이스에 연결하지는 않았지만 프로그램은 커널에 남아 있었습니다.

$ sudo bpftool prog | tail -3
783: xdp  name test  tag 5c8ba0cf164cb46c  gpl
        loaded_at 2020-05-05T13:27:08+0000  uid 0
        xlated 24B  jited 41B  memlock 4096B

정상적으로 파일 객체를 삭제할 수 있습니다 unlink(2) 그 후에는 해당 프로그램이 삭제됩니다.

$ sudo rm ./bpf-mountpoint/test
$ sudo bpftool prog show id 783
Error: get by id (783): No such file or directory

객체 삭제

객체 삭제에 관해 말하면, 후크(이벤트 생성기)에서 프로그램 연결을 끊은 후에는 단일 새 이벤트가 실행을 트리거하지 않지만 프로그램의 모든 현재 인스턴스가 정상적인 순서로 완료된다는 점을 명확히 할 필요가 있습니다. .

일부 유형의 BPF 프로그램에서는 프로그램을 즉시 교체할 수 있습니다. 시퀀스 원자성을 제공 replace = detach old program, attach new program. 이 경우 이전 버전 프로그램의 모든 활성 인스턴스가 작업을 완료하고 새 프로그램에서 새 이벤트 핸들러가 생성되며 여기서 "원자성"은 단일 이벤트가 누락되지 않음을 의미합니다.

이벤트 소스에 프로그램 연결

이 기사에서는 프로그램을 이벤트 소스에 연결하는 방법을 별도로 설명하지 않습니다. 특정 유형의 프로그램 맥락에서 이를 연구하는 것이 합리적이기 때문입니다. 센티미터. 예 아래에서는 XDP와 같은 프로그램이 어떻게 연결되는지 보여줍니다.

bpf 시스템 호출을 사용하여 객체 조작

BPF 프로그램

모든 BPF 객체는 시스템 호출을 사용하여 사용자 공간에서 생성되고 관리됩니다. bpf, 다음과 같은 프로토타입이 있습니다.

#include <linux/bpf.h>

int bpf(int cmd, union bpf_attr *attr, unsigned int size);

여기 팀이 있어요 cmd 유형의 값 중 하나입니다 enum bpf_cmd, attr — 특정 프로그램의 매개변수에 대한 포인터 및 size — 포인터에 따른 객체 크기, 즉 보통 이 sizeof(*attr). 커널 5.8에서는 시스템 호출 bpf 34가지의 다양한 명령을 지원하며, 결정 union bpf_attr 200줄을 차지합니다. 그러나 우리는 여러 기사를 통해 명령과 매개변수에 익숙해질 것이기 때문에 이것에 겁먹을 필요는 없습니다.

팀부터 시작해보자 BPF_PROG_LOADBPF 프로그램을 생성하는 , BPF 명령어 세트를 가져와 커널에 로드합니다. 로딩하는 순간 검증자가 실행되고, JIT 컴파일러가 실행되고, 성공적으로 실행되면 프로그램 파일 디스크립터가 사용자에게 반환됩니다. 우리는 이전 섹션에서 그에게 다음에 무슨 일이 일어나는지 보았습니다. BPF 객체의 수명주기에 대해.

이제 간단한 BPF 프로그램을 로드하는 사용자 정의 프로그램을 작성할 것입니다. 하지만 먼저 로드할 프로그램 종류를 결정해야 합니다. тип 그리고 이 유형의 프레임워크 내에서 검증자 테스트를 통과할 프로그램을 작성하십시오. 그러나 프로세스를 복잡하게 하지 않기 위해 기성 솔루션이 있습니다. 다음과 같은 프로그램을 사용하겠습니다. BPF_PROG_TYPE_XDP, 값을 반환합니다. XDP_PASS (모든 패키지 건너뛰기) BPF 어셈블러에서는 매우 간단해 보입니다.

r0 = 2
exit

우리가 결정한 후에 그 업로드할 예정이며 어떻게 할 것인지 알려드릴 수 있습니다.

#define _GNU_SOURCE
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/bpf.h>

static inline __u64 ptr_to_u64(const void *ptr)
{
        return (__u64) (unsigned long) ptr;
}

int main(void)
{
    struct bpf_insn insns[] = {
        {
            .code = BPF_ALU64 | BPF_MOV | BPF_K,
            .dst_reg = BPF_REG_0,
            .imm = XDP_PASS
        },
        {
            .code = BPF_JMP | BPF_EXIT
        },
    };

    union bpf_attr attr = {
        .prog_type = BPF_PROG_TYPE_XDP,
        .insns     = ptr_to_u64(insns),
        .insn_cnt  = sizeof(insns)/sizeof(insns[0]),
        .license   = ptr_to_u64("GPL"),
    };

    strncpy(attr.prog_name, "woo", sizeof(attr.prog_name));
    syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));

    for ( ;; )
        pause();
}

프로그램의 흥미로운 이벤트는 배열 정의로 시작됩니다. insns - 기계어 코드의 BPF 프로그램. 이 경우 BPF 프로그램의 각 명령어는 구조에 포함됩니다. bpf_insn. 첫 번째 요소 insns 지시를 따른다 r0 = 2, 두번째 - exit.

후퇴. 커널은 기계 코드 작성 및 커널 헤더 파일 사용을 위한 보다 편리한 매크로를 정의합니다. tools/include/linux/filter.h 우리는 쓸 수 있었다

struct bpf_insn insns[] = {
    BPF_MOV64_IMM(BPF_REG_0, XDP_PASS),
    BPF_EXIT_INSN()
};

그러나 네이티브 코드로 BPF 프로그램을 작성하는 것은 커널에서 테스트를 작성하고 BPF에 관한 기사를 작성하는 데만 필요하므로 이러한 매크로가 없다고 해서 개발자의 생활이 실제로 복잡해지는 것은 아닙니다.

BPF 프로그램을 정의한 후 이를 커널에 로드하는 단계로 넘어갑니다. 최소한의 매개변수 세트 attr 프로그램 유형, 지침 세트 및 수, 필요한 라이센스 및 이름이 포함됩니다. "woo", 다운로드 후 시스템에서 프로그램을 찾는 데 사용됩니다. 약속한 대로 프로그램은 시스템 호출을 사용하여 시스템에 로드됩니다. bpf.

프로그램이 끝나면 페이로드를 시뮬레이션하는 무한 루프가 발생합니다. 이것이 없으면 시스템 호출이 반환한 파일 설명자가 닫힐 때 프로그램이 커널에 의해 종료됩니다. bpf, 시스템에서 볼 수 없습니다.

이제 테스트할 준비가 되었습니다. 아래에서 프로그램을 어셈블하고 실행해 봅시다. strace모든 것이 제대로 작동하는지 확인하려면 다음을 수행하세요.

$ clang -g -O2 simple-prog.c -o simple-prog

$ sudo strace ./simple-prog
execve("./simple-prog", ["./simple-prog"], 0x7ffc7b553480 /* 13 vars */) = 0
...
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=2, insns=0x7ffe03c4ed50, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_V
ERSION(0, 0, 0), prog_flags=0, prog_name="woo", prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = 3
pause(

모든 것이 괜찮습니다. bpf(2) 핸들 3을 우리에게 반환했고 우리는 무한 루프에 빠졌습니다. pause(). 시스템에서 우리 프로그램을 찾아보도록 하겠습니다. 이를 위해 다른 터미널로 이동하여 유틸리티를 사용합니다. bpftool:

# bpftool prog | grep -A3 woo
390: xdp  name woo  tag 3b185187f1855c4c  gpl
        loaded_at 2020-08-31T24:66:44+0000  uid 0
        xlated 16B  jited 40B  memlock 4096B
        pids simple-prog(10381)

시스템에 로드된 프로그램이 있음을 확인합니다. woo 글로벌 ID는 390이고 현재 진행 중입니다. simple-prog 프로그램을 가리키는 열린 파일 설명자가 있습니다(그리고 만약 simple-prog 그럼 일 끝내줄게 woo 사라질 것이다). 예상대로 프로그램은 woo BPF 아키텍처에서는 16바이트(86개 명령어)의 바이너리 코드를 사용하지만 기본 형식(x64_40)에서는 이미 XNUMX바이트입니다. 원래 형식의 프로그램을 살펴보겠습니다.

# bpftool prog dump xlated id 390
   0: (b7) r0 = 2
   1: (95) exit

놀랄 일도 아니다. 이제 JIT 컴파일러에서 생성된 코드를 살펴보겠습니다.

# bpftool prog dump jited id 390
bpf_prog_3b185187f1855c4c_woo:
   0:   nopl   0x0(%rax,%rax,1)
   5:   push   %rbp
   6:   mov    %rsp,%rbp
   9:   sub    $0x0,%rsp
  10:   push   %rbx
  11:   push   %r13
  13:   push   %r14
  15:   push   %r15
  17:   pushq  $0x0
  19:   mov    $0x2,%eax
  1e:   pop    %rbx
  1f:   pop    %r15
  21:   pop    %r14
  23:   pop    %r13
  25:   pop    %rbx
  26:   leaveq
  27:   retq

별로 효과적이지 않다 exit(2), 하지만 공평하게 말하면 우리 프로그램은 너무 간단하고 중요하지 않은 프로그램의 경우 JIT 컴파일러에서 추가한 프롤로그와 에필로그가 물론 필요합니다.

지도

BPF 프로그램은 다른 BPF 프로그램과 사용자 공간의 프로그램 모두에서 액세스할 수 있는 구조화된 메모리 영역을 사용할 수 있습니다. 이러한 객체를 맵이라고 하며 이 섹션에서는 시스템 호출을 사용하여 이를 조작하는 방법을 보여줍니다. bpf.

맵의 기능이 공유 메모리에 대한 액세스에만 국한되지 않는다고 바로 가정해 보겠습니다. 예를 들어 BPF 프로그램에 대한 포인터 또는 네트워크 인터페이스에 대한 포인터, 성능 이벤트 작업을 위한 맵 등을 포함하는 특수 목적 맵이 있습니다. 독자를 혼란스럽게 하지 않기 위해 여기서는 이에 대해 이야기하지 않겠습니다. 이 외에도 동기화 문제는 예제에서는 중요하지 않기 때문에 무시합니다. 사용 가능한 지도 유형의 전체 목록은 다음에서 확인할 수 있습니다. <linux/bpf.h>, 그리고 이 섹션에서는 역사적으로 첫 번째 유형인 해시 테이블을 예로 들어 보겠습니다. BPF_MAP_TYPE_HASH.

예를 들어 C++로 해시 테이블을 생성하면 다음과 같이 됩니다. unordered_map<int,long> woo, 러시아어로 "테이블이 필요해요"를 의미합니다. woo 키 유형이 무제한인 크기 int, 값은 유형입니다. long" BPF 해시 테이블을 생성하려면 테이블의 최대 크기를 지정해야 한다는 점과 키와 값의 유형을 지정하는 대신 크기를 바이트 단위로 지정해야 한다는 점을 제외하면 거의 동일한 작업을 수행해야 합니다. . 지도를 만들려면 다음 명령을 사용하세요. BPF_MAP_CREATE 시스템 호출 bpf. 지도를 생성하는 최소한의 프로그램을 살펴보겠습니다. BPF 프로그램을 로드하는 이전 프로그램 이후에는 다음 프로그램이 간단해 보일 것입니다.

$ cat simple-map.c
#define _GNU_SOURCE
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/bpf.h>

int main(void)
{
    union bpf_attr attr = {
        .map_type = BPF_MAP_TYPE_HASH,
        .key_size = sizeof(int),
        .value_size = sizeof(int),
        .max_entries = 4,
    };
    strncpy(attr.map_name, "woo", sizeof(attr.map_name));
    syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));

    for ( ;; )
        pause();
}

여기서는 매개변수 세트를 정의합니다. attr, 여기서는 "키와 크기 값이 포함된 해시 테이블이 필요합니다. sizeof(int), 최대 XNUMX개의 요소를 넣을 수 있습니다." BPF 맵을 생성할 때 다른 매개변수를 지정할 수 있습니다. 예를 들어 프로그램 예제와 동일한 방식으로 객체 이름을 다음과 같이 지정했습니다. "woo".

프로그램을 컴파일하고 실행해 보겠습니다.

$ clang -g -O2 simple-map.c -o simple-map
$ sudo strace ./simple-map
execve("./simple-map", ["./simple-map"], 0x7ffd40a27070 /* 14 vars */) = 0
...
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4, value_size=4, max_entries=4, map_name="woo", ...}, 72) = 3
pause(

다음은 시스템 호출입니다. bpf(2) 설명자 맵 번호를 반환했습니다. 3 그런 다음 프로그램은 예상대로 시스템 호출에서 추가 명령을 기다립니다. pause(2).

이제 프로그램을 백그라운드로 보내거나 다른 터미널을 열고 유틸리티를 사용하여 개체를 살펴보겠습니다. bpftool (우리 지도는 이름으로 다른 지도와 구별할 수 있습니다):

$ sudo bpftool map
...
114: hash  name woo  flags 0x0
        key 4B  value 4B  max_entries 4  memlock 4096B
...

숫자 114는 객체의 전역 ID입니다. 시스템의 모든 프로그램은 이 ID를 사용하여 다음 명령을 사용하여 기존 지도를 열 수 있습니다. BPF_MAP_GET_FD_BY_ID 시스템 호출 bpf.

이제 해시 테이블을 가지고 놀 수 있습니다. 그 내용을 살펴보자:

$ sudo bpftool map dump id 114
Found 0 elements

비어 있는. 값을 넣어보자 hash[1] = 1:

$ sudo bpftool map update id 114 key 1 0 0 0 value 1 0 0 0

표를 다시 살펴보겠습니다.

$ sudo bpftool map dump id 114
key: 01 00 00 00  value: 01 00 00 00
Found 1 element

만세! 우리는 하나의 요소를 추가했습니다. 이를 수행하려면 바이트 수준에서 작업해야 합니다. bptftool 해시 테이블의 값이 어떤 유형인지 알 수 없습니다. (이 지식은 BTF를 사용하여 그녀에게 전달될 수 있지만 지금은 이에 대해 더 자세히 설명합니다.)

bpftool은 요소를 정확히 어떻게 읽고 추가합니까? 내부를 살펴보겠습니다.

$ sudo strace -e bpf bpftool map dump id 114
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_MAP_GET_NEXT_KEY, {map_fd=3, key=NULL, next_key=0x55856ab65280}, 120) = 0
bpf(BPF_MAP_LOOKUP_ELEM, {map_fd=3, key=0x55856ab65280, value=0x55856ab652a0}, 120) = 0
key: 01 00 00 00  value: 01 00 00 00
bpf(BPF_MAP_GET_NEXT_KEY, {map_fd=3, key=0x55856ab65280, next_key=0x55856ab65280}, 120) = -1 ENOENT

먼저 다음 명령을 사용하여 전역 ID로 지도를 열었습니다. BPF_MAP_GET_FD_BY_ID и bpf(2) 설명자 3을 우리에게 반환했습니다. 추가로 명령을 사용하여 BPF_MAP_GET_NEXT_KEY 다음을 전달하여 테이블의 첫 번째 키를 찾았습니다. NULL "이전" 키에 대한 포인터로 사용됩니다. 열쇠가 있다면 우리는 할 수 있다 BPF_MAP_LOOKUP_ELEM포인터에 값을 반환합니다. value. 다음 단계는 현재 키에 대한 포인터를 전달하여 다음 요소를 찾으려고 시도하는 것입니다. 그러나 테이블에는 하나의 요소와 명령만 포함되어 있습니다. BPF_MAP_GET_NEXT_KEY 반환 ENOENT.

좋아요, 키 1의 값을 변경해 보겠습니다. 비즈니스 로직에 등록이 필요하다고 가정해 보겠습니다. hash[1] = 2:

$ sudo strace -e bpf bpftool map update id 114 key 1 0 0 0 value 2 0 0 0
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0x55dcd72be260, value=0x55dcd72be280, flags=BPF_ANY}, 120) = 0

예상대로 매우 간단합니다. 명령은 다음과 같습니다. BPF_MAP_GET_FD_BY_ID ID로 지도를 열고 다음 명령을 실행합니다. BPF_MAP_UPDATE_ELEM 요소를 덮어씁니다.

따라서 한 프로그램에서 해시 테이블을 만든 후 다른 프로그램에서 해당 내용을 읽고 쓸 수 있습니다. 명령줄에서 이 작업을 수행할 수 있다면 시스템의 다른 프로그램도 이를 수행할 수 있습니다. 위에서 설명한 명령 외에도 사용자 공간에서 지도 작업을 하기 위한 명령은 다음과 같습니다. 다음:

• BPF_MAP_LOOKUP_ELEM: 키로 값 찾기
• BPF_MAP_UPDATE_ELEM: 값 업데이트/생성
• BPF_MAP_DELETE_ELEM: 키 제거
• BPF_MAP_GET_NEXT_KEY: 다음(또는 첫 번째) 키를 찾습니다.
• BPF_MAP_GET_NEXT_ID: 기존의 모든 지도를 탐색할 수 있습니다. 이것이 작동 방식입니다. bpftool map
• BPF_MAP_GET_FD_BY_ID: 글로벌 ID로 기존 지도를 엽니다.
• BPF_MAP_LOOKUP_AND_DELETE_ELEM: 객체의 값을 원자적으로 업데이트하고 이전 값을 반환합니다.
• BPF_MAP_FREEZE: 사용자 공간에서 지도를 변경할 수 없도록 만듭니다(이 작업은 취소할 수 없습니다).
• BPF_MAP_LOOKUP_BATCH, BPF_MAP_LOOKUP_AND_DELETE_BATCH, BPF_MAP_UPDATE_BATCH, BPF_MAP_DELETE_BATCH: 대량 작업. 예를 들어, BPF_MAP_LOOKUP_AND_DELETE_BATCH - 지도에서 모든 값을 읽고 재설정하는 신뢰할 수 있는 유일한 방법입니다.

이러한 모든 명령이 모든 맵 유형에 작동하는 것은 아니지만 일반적으로 사용자 공간에서 다른 유형의 맵을 사용하는 작업은 해시 테이블을 사용하는 작업과 완전히 동일해 보입니다.

순서를 위해 해시 테이블 실험을 마치겠습니다. 최대 XNUMX개의 키를 포함할 수 있는 테이블을 생성했다는 것을 기억하시나요? 몇 가지 요소를 더 추가해 보겠습니다.

$ sudo bpftool map update id 114 key 2 0 0 0 value 1 0 0 0
$ sudo bpftool map update id 114 key 3 0 0 0 value 1 0 0 0
$ sudo bpftool map update id 114 key 4 0 0 0 value 1 0 0 0

여태까지는 그런대로 잘됐다:

$ sudo bpftool map dump id 114
key: 01 00 00 00  value: 01 00 00 00
key: 02 00 00 00  value: 01 00 00 00
key: 04 00 00 00  value: 01 00 00 00
key: 03 00 00 00  value: 01 00 00 00
Found 4 elements

하나 더 추가해 보겠습니다.

$ sudo bpftool map update id 114 key 5 0 0 0 value 1 0 0 0
Error: update failed: Argument list too long

예상대로 우리는 성공하지 못했습니다. 오류를 더 자세히 살펴보겠습니다.

$ sudo strace -e bpf bpftool map update id 114 key 5 0 0 0 value 1 0 0 0
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=3, info_len=80, info=0x7ffe6c626da0}}, 120) = 0
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0x56049ded5260, value=0x56049ded5280, flags=BPF_ANY}, 120) = -1 E2BIG (Argument list too long)
Error: update failed: Argument list too long
+++ exited with 255 +++

모든 것이 괜찮습니다. 예상대로 팀은 BPF_MAP_UPDATE_ELEM 새로운 다섯 번째 키를 생성하려고 시도했지만 충돌이 발생했습니다. E2BIG.

따라서 BPF 프로그램을 만들고 로드할 수 있을 뿐만 아니라 사용자 공간에서 지도를 만들고 관리할 수도 있습니다. 이제 BPF 프로그램 자체의 맵을 어떻게 사용할 수 있는지 살펴보는 것이 논리적입니다. 우리는 기계 매크로 코드에서 읽기 어려운 프로그램의 언어로 이에 대해 이야기할 수 있지만 실제로는 BPF 프로그램이 실제로 어떻게 작성되고 유지되는지 보여줄 때가 왔습니다. libbpf.

(낮은 수준의 예제가 부족해서 불만인 독자들을 위해 맵을 사용한 프로그램과 이를 사용하여 만든 도우미 기능을 자세히 분석합니다. libbpf 그리고 교육 수준에서 어떤 일이 일어나는지 알려주세요. 만족스럽지 못한 독자들을 위해 대단히, 우리는 추가했습니다 예 기사의 적절한 위치에 있습니다.)

libbpf를 사용하여 BPF 프로그램 작성

기계어 코드를 사용하여 BPF 프로그램을 작성하는 것은 처음에만 흥미로울 수 있으며 그 이후에는 포만감이 생깁니다. 지금 이 순간 주의를 집중해야 합니다. llvm, BPF 아키텍처용 코드 생성을 위한 백엔드와 라이브러리가 있음 libbpf, 이를 통해 BPF 애플리케이션의 사용자 측을 작성하고 다음을 사용하여 생성된 BPF 프로그램의 코드를 로드할 수 있습니다. llvm/clang.

실제로, 이 기사와 후속 기사에서 살펴보겠지만, libbpf 그것(또는 유사한 도구) 없이도 꽤 많은 작업을 수행합니다. iproute2, libbcc, libbpf-go, 등) 사는 것이 불가능합니다. 프로젝트의 킬러 기능 중 하나 libbpf BPF CO-RE(Compile Once, Run Everywhere) - 다른 API에서 실행할 수 있는 기능을 사용하여 한 커널에서 다른 커널로 이식 가능한 BPF 프로그램을 작성할 수 있는 프로젝트입니다(예: 커널 구조가 버전에 따라 변경되는 경우) 버전). CO-RE로 작업하려면 커널이 BTF 지원으로 컴파일되어야 합니다(이 작업을 수행하는 방법은 섹션에서 설명합니다). 개발 도구. 다음 파일이 있으면 커널이 BTF로 빌드되었는지 매우 간단하게 확인할 수 있습니다.

$ ls -lh /sys/kernel/btf/vmlinux
-r--r--r-- 1 root root 2.6M Jul 29 15:30 /sys/kernel/btf/vmlinux

이 파일은 커널에서 사용되는 모든 데이터 유형에 대한 정보를 저장하며 다음을 사용하여 모든 예제에서 사용됩니다. libbpf. 다음 기사에서 CO-RE에 대해 자세히 설명하겠지만, 이번 기사에서는 다음을 사용하여 커널을 직접 빌드해 보세요. CONFIG_DEBUG_INFO_BTF.

도서관 libbpf 디렉토리에 바로 살아요 tools/lib/bpf 커널과 그 개발은 메일링 리스트를 통해 이루어집니다. [email protected]. 그러나 커널 외부에 있는 애플리케이션의 요구에 따라 별도의 저장소가 유지됩니다. https://github.com/libbpf/libbpf 커널 라이브러리는 읽기 액세스를 위해 거의 그대로 미러링됩니다.

이번 섹션에서는 다음을 사용하여 프로젝트를 생성하는 방법을 살펴보겠습니다. libbpf, 여러 가지(다소 의미 없는) 테스트 프로그램을 작성하고 그것이 어떻게 작동하는지 자세히 분석해 보겠습니다. 이를 통해 다음 섹션에서 BPF 프로그램이 맵, 커널 도우미, BTF 등과 어떻게 상호 작용하는지 정확하게 설명할 수 있습니다.

일반적으로 다음을 사용하는 프로젝트 libbpf GitHub 저장소를 git 하위 모듈로 추가하면 동일한 작업을 수행합니다.

$ mkdir /tmp/libbpf-example
$ cd /tmp/libbpf-example/
$ git init-db
Initialized empty Git repository in /tmp/libbpf-example/.git/
$ git submodule add https://github.com/libbpf/libbpf.git
Cloning into '/tmp/libbpf-example/libbpf'...
remote: Enumerating objects: 200, done.
remote: Counting objects: 100% (200/200), done.
remote: Compressing objects: 100% (103/103), done.
remote: Total 3354 (delta 101), reused 118 (delta 79), pack-reused 3154
Receiving objects: 100% (3354/3354), 2.05 MiB | 10.22 MiB/s, done.
Resolving deltas: 100% (2176/2176), done.

가다 libbpf 매우 간단합니다 :

$ cd libbpf/src
$ mkdir build
$ OBJDIR=build DESTDIR=root make -s install
$ find root
root
root/usr
root/usr/include
root/usr/include/bpf
root/usr/include/bpf/bpf_tracing.h
root/usr/include/bpf/xsk.h
root/usr/include/bpf/libbpf_common.h
root/usr/include/bpf/bpf_endian.h
root/usr/include/bpf/bpf_helpers.h
root/usr/include/bpf/btf.h
root/usr/include/bpf/bpf_helper_defs.h
root/usr/include/bpf/bpf.h
root/usr/include/bpf/libbpf_util.h
root/usr/include/bpf/libbpf.h
root/usr/include/bpf/bpf_core_read.h
root/usr/lib64
root/usr/lib64/libbpf.so.0.1.0
root/usr/lib64/libbpf.so.0
root/usr/lib64/libbpf.a
root/usr/lib64/libbpf.so
root/usr/lib64/pkgconfig
root/usr/lib64/pkgconfig/libbpf.pc

이 섹션의 다음 계획은 다음과 같습니다. 다음과 같은 BPF 프로그램을 작성하겠습니다. BPF_PROG_TYPE_XDP, 이전 예제와 동일하지만 C에서는 다음을 사용하여 컴파일합니다. clang, 그리고 이를 커널에 로드할 도우미 프로그램을 작성합니다. 다음 섹션에서는 BPF 프로그램과 보조 프로그램의 기능을 모두 확장합니다.

예: libbpf를 사용하여 완전한 애플리케이션 만들기

우선, 우리는 파일을 사용합니다 /sys/kernel/btf/vmlinux위에서 언급한 헤더 파일 형식으로 이에 상응하는 항목을 만듭니다.

$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

이 파일은 커널에서 사용 가능한 모든 데이터 구조를 저장합니다. 예를 들어 커널에서 IPv4 헤더가 정의되는 방식은 다음과 같습니다.

$ grep -A 12 'struct iphdr {' vmlinux.h
struct iphdr {
    __u8 ihl: 4;
    __u8 version: 4;
    __u8 tos;
    __be16 tot_len;
    __be16 id;
    __be16 frag_off;
    __u8 ttl;
    __u8 protocol;
    __sum16 check;
    __be32 saddr;
    __be32 daddr;
};

이제 C로 BPF 프로그램을 작성하겠습니다.

$ cat xdp-simple.bpf.c
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

SEC("xdp/simple")
int simple(void *ctx)
{
        return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

우리 프로그램은 매우 간단한 것으로 판명되었지만 여전히 많은 세부 사항에 주의를 기울여야 합니다. 먼저, 우리가 포함하는 첫 번째 헤더 파일은 다음과 같습니다. vmlinux.h, 방금 다음을 사용하여 생성한 것입니다. bpftool btf dump - 이제 커널 구조가 어떻게 생겼는지 알아보기 위해 kernel-headers 패키지를 설치할 필요가 없습니다. 다음 헤더 파일은 라이브러리에서 우리에게 제공됩니다 libbpf. 이제 매크로를 정의하는 데만 필요합니다. SEC, ELF 개체 파일의 해당 섹션으로 문자를 보냅니다. 우리 프로그램은 섹션에 포함되어 있습니다 xdp/simple, 슬래시 앞에는 프로그램 유형 BPF를 정의합니다. 이는 다음에서 사용되는 규칙입니다. libbpf, 섹션 이름에 따라 시작 시 올바른 유형으로 대체됩니다. bpf(2). BPF 프로그램 자체는 C - 매우 간단하며 한 줄로 구성됩니다. return XDP_PASS. 마지막으로 별도의 섹션 "license" 라이센스 이름이 포함되어 있습니다.

llvm/clang, 버전 >= 10.0.0 또는 더 나은 버전을 사용하여 프로그램을 컴파일할 수 있습니다(섹션 참조). 개발 도구):

$ clang --version
clang version 11.0.0 (https://github.com/llvm/llvm-project.git afc287e0abec710398465ee1f86237513f2b5091)
...

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o

흥미로운 기능 중 하나는 대상 아키텍처를 나타냅니다. -target bpf 그리고 헤더의 경로 libbpf, 우리가 최근에 설치한 것입니다. 또한 잊지 마세요 -O2, 이 옵션이 없으면 나중에 예상치 못한 일이 발생할 수 있습니다. 코드를 살펴보겠습니다. 우리가 원하는 프로그램을 작성할 수 있었나요?

$ llvm-objdump --section=xdp/simple --no-show-raw-insn -D xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       r0 = 2
       1:       exit

예, 효과가 있었습니다! 이제 프로그램이 포함된 바이너리 파일이 있고 이를 커널에 로드할 애플리케이션을 생성하려고 합니다. 이를 위해 도서관 libbpf 하위 수준 API 또는 상위 수준 API를 사용하는 두 가지 옵션을 제공합니다. 우리는 후속 연구를 위해 최소한의 노력으로 BPF 프로그램을 작성, 로드 및 연결하는 방법을 배우고 싶기 때문에 두 번째 방법으로 갈 것입니다.

먼저, 동일한 유틸리티를 사용하여 바이너리에서 프로그램의 "골격"을 생성해야 합니다. bpftool — BPF 세계의 스위스 칼(BPF의 창시자이자 유지관리자 중 한 명인 Daniel Borkman이 스위스 사람이므로 문자 그대로 받아들일 수 있음):

$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h

파일에서 xdp-simple.skel.h 여기에는 프로그램의 바이너리 코드와 객체 로드, 첨부, 삭제 등의 관리 기능이 포함되어 있습니다. 간단한 경우 이는 과잉처럼 보이지만 객체 파일에 많은 BPF 프로그램과 맵이 포함되어 있는 경우에도 작동하며 이 거대한 ELF를 로드하려면 뼈대를 생성하고 사용자 정의 애플리케이션에서 하나 또는 두 개의 함수를 호출하면 됩니다. 지금 쓰고 있습니다. 이제 계속 진행하겠습니다.

엄밀히 말하면 우리의 로더 프로그램은 간단합니다:

#include <err.h>
#include <unistd.h>
#include "xdp-simple.skel.h"

int main(int argc, char **argv)
{
    struct xdp_simple_bpf *obj;

    obj = xdp_simple_bpf__open_and_load();
    if (!obj)
        err(1, "failed to open and/or load BPF objectn");

    pause();

    xdp_simple_bpf__destroy(obj);
}

여기에 struct xdp_simple_bpf 파일에 정의되어 있음 xdp-simple.skel.h 객체 파일을 설명합니다.

struct xdp_simple_bpf {
    struct bpf_object_skeleton *skeleton;
    struct bpf_object *obj;
    struct {
        struct bpf_program *simple;
    } progs;
    struct {
        struct bpf_link *simple;
    } links;
};

여기서는 하위 수준 API의 흔적을 볼 수 있습니다. struct bpf_program *simple и struct bpf_link *simple. 첫 번째 구조는 섹션에 작성된 프로그램을 구체적으로 설명합니다. xdp/simple, 두 번째는 프로그램이 이벤트 소스에 연결하는 방법을 설명합니다.

기능 xdp_simple_bpf__open_and_load, ELF 개체를 열고 구문 분석하고 모든 구조와 하위 구조를 생성한 다음(프로그램 외에도 ELF에는 데이터, 읽기 전용 데이터, 디버깅 정보, 라이센스 등의 다른 섹션도 포함되어 있음) 시스템을 사용하여 커널에 로드합니다. 부르다 bpf, 프로그램을 컴파일하고 실행하여 확인할 수 있습니다.

$ clang -O2 -I ./libbpf/src/root/usr/include/ xdp-simple.c -o xdp-simple ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz

$ sudo strace -e bpf ./xdp-simple
...
bpf(BPF_BTF_LOAD, 0x7ffdb8fd9670, 120)  = 3
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=2, insns=0xdfd580, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_VERSION(5, 8, 0), prog_flags=0, prog_name="simple", prog_ifindex=0, expected_attach_type=0x25 /* BPF_??? */, ...}, 120) = 4

이제 다음을 사용하여 프로그램을 살펴보겠습니다. bpftool. 그녀의 ID를 찾아보자:

# bpftool p | grep -A4 simple
463: xdp  name simple  tag 3b185187f1855c4c  gpl
        loaded_at 2020-08-01T01:59:49+0000  uid 0
        xlated 16B  jited 40B  memlock 4096B
        btf_id 185
        pids xdp-simple(16498)

및 덤프(명령의 단축 형식을 사용합니다. bpftool prog dump xlated):

# bpftool p d x id 463
int simple(void *ctx):
; return XDP_PASS;
   0: (b7) r0 = 2
   1: (95) exit

뭔가 새로운 것을! 프로그램은 C 소스 파일의 덩어리를 인쇄했습니다. 이는 라이브러리에 의해 수행되었습니다. libbpf, 바이너리에서 디버그 섹션을 찾아 BTF 개체로 컴파일하고 다음을 사용하여 커널에 로드했습니다. BPF_BTF_LOAD, 명령을 사용하여 프로그램을 로드할 때 결과 파일 설명자를 지정했습니다. BPG_PROG_LOAD.

커널 도우미

BPF 프로그램은 "외부" 기능(커널 도우미)을 실행할 수 있습니다. 이러한 도우미 기능을 사용하면 BPF 프로그램이 커널 구조에 액세스하고, 맵을 관리하고, 성능 이벤트 생성, 하드웨어 제어(예: 패킷 리디렉션) 등 "실제 세계"와 통신할 수도 있습니다.

예: bpf_get_smp_processor_id

"예를 통한 학습" 패러다임의 틀 내에서 도우미 기능 중 하나를 고려해 보겠습니다. bpf_get_smp_processor_id(), 확실한 파일에 kernel/bpf/helpers.c. 이를 호출한 BPF 프로그램이 실행 중인 프로세서의 번호를 반환합니다. 그러나 우리는 구현이 한 줄로 이루어진다는 사실만큼 의미론에 관심이 없습니다.

BPF_CALL_0(bpf_get_smp_processor_id)
{
    return smp_processor_id();
}

BPF 도우미 함수 정의는 Linux 시스템 호출 정의와 유사합니다. 예를 들어, 인수가 없는 함수가 정의되어 있습니다. (가령 세 개의 인수를 취하는 함수는 매크로를 사용하여 정의됩니다. BPF_CALL_3. 최대 인수 수는 XNUMX개입니다.) 그러나 이는 정의의 첫 번째 부분일 뿐입니다. 두 번째 부분은 유형 구조를 정의하는 것입니다. struct bpf_func_proto에는 검증자가 이해하는 도우미 함수에 대한 설명이 포함되어 있습니다.

const struct bpf_func_proto bpf_get_smp_processor_id_proto = {
    .func     = bpf_get_smp_processor_id,
    .gpl_only = false,
    .ret_type = RET_INTEGER,
};

도우미 함수 등록

특정 유형의 BPF 프로그램이 이 함수를 사용하려면 이를 등록해야 합니다. BPF_PROG_TYPE_XDP 함수는 커널에 정의되어 있습니다 xdp_func_proto, 도우미 기능 ID를 통해 XDP가 이 기능을 지원하는지 여부를 결정합니다. 우리의 기능은 поддерживает:

static const struct bpf_func_proto *
xdp_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
{
    switch (func_id) {
    ...
    case BPF_FUNC_get_smp_processor_id:
        return &bpf_get_smp_processor_id_proto;
    ...
    }
}

새로운 BPF 프로그램 유형은 파일에 "정의"됩니다. include/linux/bpf_types.h 매크로를 사용하여 BPF_PROG_TYPE. 논리적인 정의이기 때문에 따옴표로 정의하고, C 언어 용어에서는 구체적인 구조 전체 집합의 정의가 다른 곳에서 발생합니다. 특히 파일에는 kernel/bpf/verifier.c 파일의 모든 정의 bpf_types.h 구조체 배열을 만드는 데 사용됩니다. bpf_verifier_ops[]:

static const struct bpf_verifier_ops *const bpf_verifier_ops[] = {
#define BPF_PROG_TYPE(_id, _name, prog_ctx_type, kern_ctx_type) 
    [_id] = & _name ## _verifier_ops,
#include <linux/bpf_types.h>
#undef BPF_PROG_TYPE
};

즉, BPF 프로그램의 각 유형에 대해 해당 유형의 데이터 구조에 대한 포인터가 정의됩니다. struct bpf_verifier_ops, 이는 값으로 초기화됩니다. _name ## _verifier_ops, 즉., xdp_verifier_ops 에 xdp. 구조 xdp_verifier_ops 에 의해 결정 파일에 net/core/filter.c 다음과 같이

const struct bpf_verifier_ops xdp_verifier_ops = {
    .get_func_proto     = xdp_func_proto,
    .is_valid_access    = xdp_is_valid_access,
    .convert_ctx_access = xdp_convert_ctx_access,
    .gen_prologue       = bpf_noop_prologue,
};

여기서 우리는 친숙한 기능을 봅니다. xdp_func_proto, 문제가 발생할 때마다 검증 프로그램을 실행합니다. 어떤 종류 BPF 프로그램 내부의 함수는 다음을 참조하세요. verifier.c.

가상의 BPF 프로그램이 이 함수를 어떻게 사용하는지 살펴보겠습니다. bpf_get_smp_processor_id. 이를 위해 이전 섹션의 프로그램을 다음과 같이 다시 작성합니다.

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

SEC("xdp/simple")
int simple(void *ctx)
{
    if (bpf_get_smp_processor_id() != 0)
        return XDP_DROP;
    return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

상징 bpf_get_smp_processor_id 에 의해 결정 в <bpf/bpf_helper_defs.h> 도서관 libbpf как

static u32 (*bpf_get_smp_processor_id)(void) = (void *) 8;

그건, bpf_get_smp_processor_id 값이 8인 함수 포인터입니다. 여기서 8은 값입니다. BPF_FUNC_get_smp_processor_id типа enum bpf_fun_id, 이는 파일에 정의되어 있습니다. vmlinux.h (파일 bpf_helper_defs.h 커널에서는 스크립트에 의해 생성되므로 "마법의" 숫자는 괜찮습니다). 이 함수는 인수를 사용하지 않고 다음 유형의 값을 반환합니다. __u32. 프로그램에서 이를 실행하면, clang 명령어를 생성한다 BPF_CALL "올바른 종류" 프로그램을 컴파일하고 섹션을 살펴 보겠습니다. xdp/simple:

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o
$ llvm-objdump -D --section=xdp/simple xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       bf 01 00 00 00 00 00 00 r1 = r0
       2:       67 01 00 00 20 00 00 00 r1 <<= 32
       3:       77 01 00 00 20 00 00 00 r1 >>= 32
       4:       b7 00 00 00 02 00 00 00 r0 = 2
       5:       15 01 01 00 00 00 00 00 if r1 == 0 goto +1 <LBB0_2>
       6:       b7 00 00 00 01 00 00 00 r0 = 1

0000000000000038 <LBB0_2>:
       7:       95 00 00 00 00 00 00 00 exit

첫 번째 줄에는 지침이 표시됩니다. call, 매개변수 IMM 이는 8과 같고, SRC_REG - 영. 검증자가 사용하는 ABI 계약에 따르면 이는 도우미 함수 번호 XNUMX에 대한 호출입니다. 일단 실행되면 논리는 간단합니다. 레지스터의 반환 값 r0 복사됨 r1 2,3행에서는 다음 유형으로 변환됩니다. u32 — 상위 32비트가 지워집니다. 4,5,6,7행에서는 2(XDP_PASS) 또는 1(XDP_DROP) 0행의 도우미 함수가 XNUMX 또는 XNUMX이 아닌 값을 반환했는지 여부에 따라 달라집니다.

스스로 테스트해보자: 프로그램을 로드하고 출력을 살펴보자. bpftool prog dump xlated:

$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h
$ clang -O2 -g -I ./libbpf/src/root/usr/include/ -o xdp-simple xdp-simple.c ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz
$ sudo ./xdp-simple &
[2] 10914

$ sudo bpftool p | grep simple
523: xdp  name simple  tag 44c38a10c657e1b0  gpl
        pids xdp-simple(10915)

$ sudo bpftool p d x id 523
int simple(void *ctx):
; if (bpf_get_smp_processor_id() != 0)
   0: (85) call bpf_get_smp_processor_id#114128
   1: (bf) r1 = r0
   2: (67) r1 <<= 32
   3: (77) r1 >>= 32
   4: (b7) r0 = 2
; }
   5: (15) if r1 == 0x0 goto pc+1
   6: (b7) r0 = 1
   7: (95) exit

좋습니다. 검증자가 올바른 커널 도우미를 찾았습니다.

예: 인수를 전달하고 마지막으로 프로그램을 실행합니다!

모든 실행 수준 도우미 함수에는 프로토타입이 있습니다.

u64 fn(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)

도우미 함수에 대한 매개변수는 레지스터에 전달됩니다. r1-r5, 값은 레지스터에 반환됩니다. r0. XNUMX개 이상의 인수를 취하는 함수는 없으며 이에 대한 지원은 향후 추가되지 않을 것으로 예상됩니다.

새로운 커널 도우미와 BPF가 매개변수를 전달하는 방법을 살펴보겠습니다. 다시 쓰자 xdp-simple.bpf.c 다음과 같습니다(나머지 줄은 변경되지 않았습니다).

SEC("xdp/simple")
int simple(void *ctx)
{
    bpf_printk("running on CPU%un", bpf_get_smp_processor_id());
    return XDP_PASS;
}

우리 프로그램은 실행 중인 CPU의 번호를 인쇄합니다. 이를 컴파일하고 코드를 살펴보겠습니다.

$ llvm-objdump -D --section=xdp/simple --no-show-raw-insn xdp-simple.bpf.o

0000000000000000 <simple>:
       0:       r1 = 10
       1:       *(u16 *)(r10 - 8) = r1
       2:       r1 = 8441246879787806319 ll
       4:       *(u64 *)(r10 - 16) = r1
       5:       r1 = 2334956330918245746 ll
       7:       *(u64 *)(r10 - 24) = r1
       8:       call 8
       9:       r1 = r10
      10:       r1 += -24
      11:       r2 = 18
      12:       r3 = r0
      13:       call 6
      14:       r0 = 2
      15:       exit

0-7행에서 문자열을 작성합니다. running on CPU%un, 그리고 8번째 줄에서 익숙한 것을 실행합니다. bpf_get_smp_processor_id. 9-12행에서는 도우미 인수를 준비합니다. bpf_printk - 레지스터 r1, r2, r3. 왜 XNUMX개가 아니고 XNUMX개가 있는 걸까요? 왜냐하면 bpf_printk - 이것은 매크로 래퍼입니다 진짜 도우미 주위에 bpf_trace_printk, 형식 문자열의 크기를 전달해야 합니다.

이제 두 줄을 추가해 보겠습니다. xdp-simple.c우리 프로그램이 인터페이스에 연결되도록 lo 그리고 정말 시작했어요!

$ cat xdp-simple.c
#include <linux/if_link.h>
#include <err.h>
#include <unistd.h>
#include "xdp-simple.skel.h"

int main(int argc, char **argv)
{
    __u32 flags = XDP_FLAGS_SKB_MODE;
    struct xdp_simple_bpf *obj;

    obj = xdp_simple_bpf__open_and_load();
    if (!obj)
        err(1, "failed to open and/or load BPF objectn");

    bpf_set_link_xdp_fd(1, -1, flags);
    bpf_set_link_xdp_fd(1, bpf_program__fd(obj->progs.simple), flags);

cleanup:
    xdp_simple_bpf__destroy(obj);
}

여기서는 함수를 사용합니다. bpf_set_link_xdp_fd, XDP 유형 BPF 프로그램을 네트워크 인터페이스에 연결합니다. 인터페이스 번호를 하드코딩했습니다. lo, 이는 항상 1입니다. 이전 프로그램이 연결되어 있는 경우 먼저 기존 프로그램을 분리하기 위해 함수를 두 번 실행합니다. 이제는 도전이 필요하지 않습니다. pause 또는 무한 루프: 로더 프로그램은 종료되지만 BPF 프로그램은 이벤트 소스에 연결되어 있으므로 종료되지 않습니다. 다운로드 및 연결이 성공적으로 완료되면, 도착하는 각 네트워크 패킷에 대해 프로그램이 시작됩니다. lo.

프로그램을 다운로드하고 인터페이스를 살펴 보겠습니다. lo:

$ sudo ./xdp-simple
$ sudo bpftool p | grep simple
669: xdp  name simple  tag 4fca62e77ccb43d6  gpl
$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 669

다운로드한 프로그램의 ID는 669이며 인터페이스에도 동일한 ID가 표시됩니다. lo. 우리는 다음 주소로 몇 개의 패키지를 보낼 것입니다. 127.0.0.1 (요청 + 응답):

$ ping -c1 localhost

이제 디버그 가상 파일의 내용을 살펴보겠습니다. /sys/kernel/debug/tracing/trace_pipe, 어느 bpf_printk 그의 메시지를 씁니다:

# cat /sys/kernel/debug/tracing/trace_pipe
ping-13937 [000] d.s1 442015.377014: bpf_trace_printk: running on CPU0
ping-13937 [000] d.s1 442015.377027: bpf_trace_printk: running on CPU0

두 개의 패키지가 발견되었습니다. lo CPU0에서 처리되었습니다. 첫 번째 본격적인 의미 없는 BPF 프로그램이 작동했습니다!

주목할 가치가 있습니다. bpf_printk 디버그 파일에 기록하는 것은 아무것도 아닙니다. 이것은 프로덕션에서 사용하기에 가장 성공적인 도우미는 아니지만 우리의 목표는 간단한 것을 보여주는 것이었습니다.

BPF 프로그램에서 지도에 액세스

예: BPF 프로그램의 맵 사용

이전 섹션에서는 사용자 공간에서 맵을 생성하고 사용하는 방법을 배웠으며 이제 커널 부분을 살펴보겠습니다. 평소처럼 예를 들어 시작해 보겠습니다. 프로그램을 다시 작성해보자 xdp-simple.bpf.c 다음과 같이

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __uint(max_entries, 8);
    __type(key, u32);
    __type(value, u64);
} woo SEC(".maps");

SEC("xdp/simple")
int simple(void *ctx)
{
    u32 key = bpf_get_smp_processor_id();
    u32 *val;

    val = bpf_map_lookup_elem(&woo, &key);
    if (!val)
        return XDP_ABORTED;

    *val += 1;

    return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

프로그램 시작 부분에 지도 정의를 추가했습니다. woo: 다음과 같은 값을 저장하는 8요소 배열입니다. u64 (C에서는 다음과 같은 배열을 정의합니다. u64 woo[8]). 프로그램에서 "xdp/simple" 현재 프로세서 번호를 변수로 가져옵니다. key 그런 다음 도우미 기능을 사용하여 bpf_map_lookup_element 배열의 해당 항목에 대한 포인터를 얻고 XNUMX씩 증가합니다. 러시아어로 번역: CPU가 들어오는 패킷을 처리한 통계를 계산합니다. 프로그램을 실행해 봅시다:

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o
$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h
$ clang -O2 -g -I ./libbpf/src/root/usr/include/ -o xdp-simple xdp-simple.c ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz
$ sudo ./xdp-simple

그녀가 연결되어 있는지 확인해보자 lo 그리고 패킷을 보내세요:

$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 108

$ for s in `seq 234`; do sudo ping -f -c 100 127.0.0.1 >/dev/null 2>&1; done

이제 배열의 내용을 살펴보겠습니다.

$ sudo bpftool map dump name woo
[
    { "key": 0, "value": 0 },
    { "key": 1, "value": 400 },
    { "key": 2, "value": 0 },
    { "key": 3, "value": 0 },
    { "key": 4, "value": 0 },
    { "key": 5, "value": 0 },
    { "key": 6, "value": 0 },
    { "key": 7, "value": 46400 }
]

거의 모든 프로세스가 CPU7에서 처리되었습니다. 이것은 우리에게 중요하지 않습니다. 가장 중요한 것은 프로그램이 작동하고 BPF 프로그램에서 맵에 액세스하는 방법을 이해한다는 것입니다. хелперов bpf_mp_*.

신비한 색인

따라서 다음과 같은 호출을 사용하여 BPF 프로그램에서 지도에 액세스할 수 있습니다.

val = bpf_map_lookup_elem(&woo, &key);

도우미 함수는 다음과 같습니다.

void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)

하지만 우리는 포인터를 전달하고 있습니다 &woo 이름없는 구조로 struct { ... }...

프로그램 어셈블러를 보면 다음과 같은 값을 알 수 있습니다. &woo 실제로 정의되지 않았습니다(라인 4):

llvm-objdump -D --section xdp/simple xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0
       2:       bf a2 00 00 00 00 00 00 r2 = r10
       3:       07 02 00 00 fc ff ff ff r2 += -4
       4:       18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
       6:       85 00 00 00 01 00 00 00 call 1
...

재배치에 포함됩니다.

$ llvm-readelf -r xdp-simple.bpf.o | head -4

Relocation section '.relxdp/simple' at offset 0xe18 contains 1 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name
0000000000000020  0000002700000001 R_BPF_64_64            0000000000000000 woo

그러나 이미 로드된 프로그램을 보면 올바른 맵에 대한 포인터를 볼 수 있습니다(라인 4).

$ sudo bpftool prog dump x name simple
int simple(void *ctx):
   0: (85) call bpf_get_smp_processor_id#114128
   1: (63) *(u32 *)(r10 -4) = r0
   2: (bf) r2 = r10
   3: (07) r2 += -4
   4: (18) r1 = map[id:64]
...

따라서 우리는 로더 프로그램을 시작할 때 다음 링크에 대한 링크가 있다고 결론을 내릴 수 있습니다. &woo 도서관이 있는 것으로 대체되었습니다 libbpf. 먼저 출력을 살펴보겠습니다. strace:

$ sudo strace -e bpf ./xdp-simple
...
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, key_size=4, value_size=8, max_entries=8, map_name="woo", ...}, 120) = 4
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, prog_name="simple", ...}, 120) = 5

우리는 그것을 본다. libbpf 지도를 만들었어요 woo 그런 다음 우리 프로그램을 다운로드했습니다. simple. 프로그램을 로드하는 방법을 자세히 살펴보겠습니다.

• 부르다 xdp_simple_bpf__open_and_load 파일에서 xdp-simple.skel.h
• 원인이 되는 xdp_simple_bpf__load 파일에서 xdp-simple.skel.h
• 원인이 되는 bpf_object__load_skeleton 파일에서 libbpf/src/libbpf.c
• 원인이 되는 bpf_object__load_xattr 으로 libbpf/src/libbpf.c

무엇보다도 마지막 함수는 다음을 호출합니다. bpf_object__create_maps, 기존 맵을 생성하거나 열어 이를 파일 설명자로 변환합니다. (여기서 우리가 보는 곳은 BPF_MAP_CREATE 출력에서 strace.) 다음으로 함수가 호출됩니다. bpf_object__relocate 우리가 본 것을 기억하기 때문에 우리에게 관심이 있는 사람은 바로 그녀입니다. woo 재배치 테이블에서. 그것을 탐구하면서 우리는 결국 다음 함수에 있는 자신을 발견합니다. bpf_program__relocate, 그리고 지도 재배치를 다룬다:

case RELO_LD64:
    insn[0].src_reg = BPF_PSEUDO_MAP_FD;
    insn[0].imm = obj->maps[relo->map_idx].fd;
    break;

그래서 우리는 지시를 따릅니다.

18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll

그 안의 소스 레지스터를 다음으로 대체합니다. BPF_PSEUDO_MAP_FD, 첫 번째 IMM은 맵의 파일 설명자이며, 예를 들어 다음과 같은 경우 0xdeadbeef, 결과적으로 우리는 지시를 받게 될 것입니다

18 11 00 00 ef eb ad de 00 00 00 00 00 00 00 00 r1 = 0 ll

이는 지도 정보가 로드된 특정 BPF 프로그램으로 전송되는 방식입니다. 이 경우 다음을 사용하여 지도를 만들 수 있습니다. BPF_MAP_CREATE, 다음을 사용하여 ID로 열었습니다. BPF_MAP_GET_FD_BY_ID.

합계, 사용시 libbpf 알고리즘은 다음과 같습니다.

• 컴파일하는 동안 지도에 대한 링크를 위해 재배치 테이블에 레코드가 생성됩니다.
• libbpf ELF 객체 북을 열고, 사용된 모든 맵을 찾아 그에 대한 파일 설명자를 생성합니다.
• 파일 설명자는 명령어의 일부로 커널에 로드됩니다. LD64

여러분이 상상할 수 있듯이 앞으로 더 많은 것이 있을 것이며 우리는 핵심을 조사해야 할 것입니다. 다행히도 단서가 있습니다. 의미를 적어 두었습니다. BPF_PSEUDO_MAP_FD 소스 기록부에 기록하면 우리는 그것을 묻어 모든 성도들의 성소로 인도할 것입니다. kernel/bpf/verifier.c, 고유한 이름을 가진 함수는 파일 설명자를 유형 구조의 주소로 대체합니다. struct bpf_map:

static int replace_map_fd_with_map_ptr(struct bpf_verifier_env *env) {
    ...

    f = fdget(insn[0].imm);
    map = __bpf_map_get(f);
    if (insn->src_reg == BPF_PSEUDO_MAP_FD) {
        addr = (unsigned long)map;
    }
    insn[0].imm = (u32)addr;
    insn[1].imm = addr >> 32;

(전체 코드를 찾을 수 있습니다 링크). 따라서 알고리즘을 확장할 수 있습니다.

• 프로그램을 로드하는 동안 검증자는 맵의 올바른 사용을 확인하고 해당 구조의 주소를 씁니다. struct bpf_map

다음을 사용하여 ELF 바이너리를 다운로드할 때 libbpf 더 많은 일이 진행되고 있지만 이에 대해서는 다른 기사에서 논의하겠습니다.

libbpf 없이 프로그램 및 맵 로드

약속한 대로, 도움 없이 지도를 사용하는 프로그램을 만들고 로드하는 방법을 알고 싶은 독자를 위한 예가 있습니다. libbpf. 이는 종속성을 구축할 수 없거나 모든 비트를 저장할 수 없는 환경에서 작업하거나 다음과 같은 프로그램을 작성할 때 유용할 수 있습니다. ply, 즉석에서 BPF 바이너리 코드를 생성합니다.

논리를 더 쉽게 따르도록 하기 위해 이러한 목적에 맞게 예제를 다시 작성하겠습니다. xdp-simple. 이 예에서 논의된 프로그램의 전체 및 약간 확장된 코드는 다음에서 찾을 수 있습니다. 요점.

우리 애플리케이션의 논리는 다음과 같습니다.

• 유형 맵 생성 BPF_MAP_TYPE_ARRAY 명령을 사용하여 BPF_MAP_CREATE,
• 이 지도를 사용하는 프로그램을 만들고,
• 프로그램을 인터페이스에 연결 lo,

인간으로 번역하면

int main(void)
{
    int map_fd, prog_fd;

    map_fd = map_create();
    if (map_fd < 0)
        err(1, "bpf: BPF_MAP_CREATE");

    prog_fd = prog_load(map_fd);
    if (prog_fd < 0)
        err(1, "bpf: BPF_PROG_LOAD");

    xdp_attach(1, prog_fd);
}

여기에 map_create 시스템 호출에 대한 첫 번째 예에서 했던 것과 같은 방식으로 맵을 생성합니다. bpf - “커널, 다음과 같은 8개 요소의 배열 형태로 새 맵을 만들어 주세요. __u64 파일 설명자를 돌려주세요.":

static int map_create()
{
    union bpf_attr attr;

    memset(&attr, 0, sizeof(attr));
    attr.map_type = BPF_MAP_TYPE_ARRAY,
    attr.key_size = sizeof(__u32),
    attr.value_size = sizeof(__u64),
    attr.max_entries = 8,
    strncpy(attr.map_name, "woo", sizeof(attr.map_name));
    return syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));
}

프로그램은 로드하기도 쉽습니다.

static int prog_load(int map_fd)
{
    union bpf_attr attr;
    struct bpf_insn insns[] = {
        ...
    };

    memset(&attr, 0, sizeof(attr));
    attr.prog_type = BPF_PROG_TYPE_XDP;
    attr.insns     = ptr_to_u64(insns);
    attr.insn_cnt  = sizeof(insns)/sizeof(insns[0]);
    attr.license   = ptr_to_u64("GPL");
    strncpy(attr.prog_name, "woo", sizeof(attr.prog_name));
    return syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));
}

까다로운 부분 prog_load BPF 프로그램을 구조체의 배열로 정의합니다. struct bpf_insn insns[]. 하지만 우리는 C에 있는 프로그램을 사용하고 있기 때문에 약간의 속임수를 쓸 수 있습니다.

$ llvm-objdump -D --section xdp/simple xdp-simple.bpf.o

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0
       2:       bf a2 00 00 00 00 00 00 r2 = r10
       3:       07 02 00 00 fc ff ff ff r2 += -4
       4:       18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
       6:       85 00 00 00 01 00 00 00 call 1
       7:       b7 01 00 00 00 00 00 00 r1 = 0
       8:       15 00 04 00 00 00 00 00 if r0 == 0 goto +4 <LBB0_2>
       9:       61 01 00 00 00 00 00 00 r1 = *(u32 *)(r0 + 0)
      10:       07 01 00 00 01 00 00 00 r1 += 1
      11:       63 10 00 00 00 00 00 00 *(u32 *)(r0 + 0) = r1
      12:       b7 01 00 00 02 00 00 00 r1 = 2

0000000000000068 <LBB0_2>:
      13:       bf 10 00 00 00 00 00 00 r0 = r1
      14:       95 00 00 00 00 00 00 00 exit

전체적으로 우리는 다음과 같은 구조의 형태로 14개의 명령어를 작성해야 합니다. struct bpf_insn (조언: 위에서 덤프를 가져오고 지침 섹션을 다시 읽고 엽니다. linux/bpf.h и linux/bpf_common.h 그리고 결정하려고 struct bpf_insn insns[] 스스로):

struct bpf_insn insns[] = {
    /* 85 00 00 00 08 00 00 00 call 8 */
    {
        .code = BPF_JMP | BPF_CALL,
        .imm = 8,
    },

    /* 63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0 */
    {
        .code = BPF_MEM | BPF_STX,
        .off = -4,
        .src_reg = BPF_REG_0,
        .dst_reg = BPF_REG_10,
    },

    /* bf a2 00 00 00 00 00 00 r2 = r10 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_X,
        .src_reg = BPF_REG_10,
        .dst_reg = BPF_REG_2,
    },

    /* 07 02 00 00 fc ff ff ff r2 += -4 */
    {
        .code = BPF_ALU64 | BPF_ADD | BPF_K,
        .dst_reg = BPF_REG_2,
        .imm = -4,
    },

    /* 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll */
    {
        .code = BPF_LD | BPF_DW | BPF_IMM,
        .src_reg = BPF_PSEUDO_MAP_FD,
        .dst_reg = BPF_REG_1,
        .imm = map_fd,
    },
    { }, /* placeholder */

    /* 85 00 00 00 01 00 00 00 call 1 */
    {
        .code = BPF_JMP | BPF_CALL,
        .imm = 1,
    },

    /* b7 01 00 00 00 00 00 00 r1 = 0 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 0,
    },

    /* 15 00 04 00 00 00 00 00 if r0 == 0 goto +4 <LBB0_2> */
    {
        .code = BPF_JMP | BPF_JEQ | BPF_K,
        .off = 4,
        .src_reg = BPF_REG_0,
        .imm = 0,
    },

    /* 61 01 00 00 00 00 00 00 r1 = *(u32 *)(r0 + 0) */
    {
        .code = BPF_MEM | BPF_LDX,
        .off = 0,
        .src_reg = BPF_REG_0,
        .dst_reg = BPF_REG_1,
    },

    /* 07 01 00 00 01 00 00 00 r1 += 1 */
    {
        .code = BPF_ALU64 | BPF_ADD | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 1,
    },

    /* 63 10 00 00 00 00 00 00 *(u32 *)(r0 + 0) = r1 */
    {
        .code = BPF_MEM | BPF_STX,
        .src_reg = BPF_REG_1,
        .dst_reg = BPF_REG_0,
    },

    /* b7 01 00 00 02 00 00 00 r1 = 2 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 2,
    },

    /* <LBB0_2>: bf 10 00 00 00 00 00 00 r0 = r1 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_X,
        .src_reg = BPF_REG_1,
        .dst_reg = BPF_REG_0,
    },

    /* 95 00 00 00 00 00 00 00 exit */
    {
        .code = BPF_JMP | BPF_EXIT
    },
};

이 글을 직접 작성하지 않은 사람들을 위한 연습 - 찾기 map_fd.

우리 프로그램에는 공개되지 않은 부분이 하나 더 남아 있습니다. xdp_attach. 안타깝게도 XDP와 같은 프로그램은 시스템 호출을 사용하여 연결할 수 없습니다. bpf. BPF와 XDP를 만든 사람들은 온라인 Linux 커뮤니티 출신이었습니다. 즉, 그들은 그들에게 가장 친숙한 것을 사용했다는 의미입니다. 보통의 people) 커널과 상호작용하기 위한 인터페이스: 넷링크 소켓, 또한보십시오 RFC3549. 가장 간단한 구현 방법 xdp_attach 다음에서 코드를 복사하고 있습니다. libbpf, 즉 파일에서 netlink.c, 이것이 우리가 한 일이며, 조금 단축했습니다:

netlink 소켓의 세계에 오신 것을 환영합니다

netlink 소켓 유형 열기 NETLINK_ROUTE:

int netlink_open(__u32 *nl_pid)
{
    struct sockaddr_nl sa;
    socklen_t addrlen;
    int one = 1, ret;
    int sock;

    memset(&sa, 0, sizeof(sa));
    sa.nl_family = AF_NETLINK;

    sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
    if (sock < 0)
        err(1, "socket");

    if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK, &one, sizeof(one)) < 0)
        warnx("netlink error reporting not supported");

    if (bind(sock, (struct sockaddr *)&sa, sizeof(sa)) < 0)
        err(1, "bind");

    addrlen = sizeof(sa);
    if (getsockname(sock, (struct sockaddr *)&sa, &addrlen) < 0)
        err(1, "getsockname");

    *nl_pid = sa.nl_pid;
    return sock;
}

우리는 이 소켓에서 다음을 읽습니다:

static int bpf_netlink_recv(int sock, __u32 nl_pid, int seq)
{
    bool multipart = true;
    struct nlmsgerr *errm;
    struct nlmsghdr *nh;
    char buf[4096];
    int len, ret;

    while (multipart) {
        multipart = false;
        len = recv(sock, buf, sizeof(buf), 0);
        if (len < 0)
            err(1, "recv");

        if (len == 0)
            break;

        for (nh = (struct nlmsghdr *)buf; NLMSG_OK(nh, len);
                nh = NLMSG_NEXT(nh, len)) {
            if (nh->nlmsg_pid != nl_pid)
                errx(1, "wrong pid");
            if (nh->nlmsg_seq != seq)
                errx(1, "INVSEQ");
            if (nh->nlmsg_flags & NLM_F_MULTI)
                multipart = true;
            switch (nh->nlmsg_type) {
                case NLMSG_ERROR:
                    errm = (struct nlmsgerr *)NLMSG_DATA(nh);
                    if (!errm->error)
                        continue;
                    ret = errm->error;
                    // libbpf_nla_dump_errormsg(nh); too many code to copy...
                    goto done;
                case NLMSG_DONE:
                    return 0;
                default:
                    break;
            }
        }
    }
    ret = 0;
done:
    return ret;
}

마지막으로 소켓을 열고 파일 설명자가 포함된 특별한 메시지를 보내는 함수는 다음과 같습니다.

static int xdp_attach(int ifindex, int prog_fd)
{
    int sock, seq = 0, ret;
    struct nlattr *nla, *nla_xdp;
    struct {
        struct nlmsghdr  nh;
        struct ifinfomsg ifinfo;
        char             attrbuf[64];
    } req;
    __u32 nl_pid = 0;

    sock = netlink_open(&nl_pid);
    if (sock < 0)
        return sock;

    memset(&req, 0, sizeof(req));
    req.nh.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
    req.nh.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
    req.nh.nlmsg_type = RTM_SETLINK;
    req.nh.nlmsg_pid = 0;
    req.nh.nlmsg_seq = ++seq;
    req.ifinfo.ifi_family = AF_UNSPEC;
    req.ifinfo.ifi_index = ifindex;

    /* started nested attribute for XDP */
    nla = (struct nlattr *)(((char *)&req)
            + NLMSG_ALIGN(req.nh.nlmsg_len));
    nla->nla_type = NLA_F_NESTED | IFLA_XDP;
    nla->nla_len = NLA_HDRLEN;

    /* add XDP fd */
    nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
    nla_xdp->nla_type = IFLA_XDP_FD;
    nla_xdp->nla_len = NLA_HDRLEN + sizeof(int);
    memcpy((char *)nla_xdp + NLA_HDRLEN, &prog_fd, sizeof(prog_fd));
    nla->nla_len += nla_xdp->nla_len;

    /* if user passed in any flags, add those too */
    __u32 flags = XDP_FLAGS_SKB_MODE;
    nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
    nla_xdp->nla_type = IFLA_XDP_FLAGS;
    nla_xdp->nla_len = NLA_HDRLEN + sizeof(flags);
    memcpy((char *)nla_xdp + NLA_HDRLEN, &flags, sizeof(flags));
    nla->nla_len += nla_xdp->nla_len;

    req.nh.nlmsg_len += NLA_ALIGN(nla->nla_len);

    if (send(sock, &req, req.nh.nlmsg_len, 0) < 0)
        err(1, "send");
    ret = bpf_netlink_recv(sock, nl_pid, seq);

cleanup:
    close(sock);
    return ret;
}

이제 모든 테스트 준비가 완료되었습니다.

$ cc nolibbpf.c -o nolibbpf
$ sudo strace -e bpf ./nolibbpf
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, map_name="woo", ...}, 72) = 3
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=15, prog_name="woo", ...}, 72) = 4
+++ exited with 0 +++

우리 프로그램이 다음과 연결되었는지 확인해 봅시다. lo:

$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 160

핑을 보내고 지도를 살펴보겠습니다.

$ for s in `seq 234`; do sudo ping -f -c 100 127.0.0.1 >/dev/null 2>&1; done
$ sudo bpftool m dump name woo
key: 00 00 00 00  value: 90 01 00 00 00 00 00 00
key: 01 00 00 00  value: 00 00 00 00 00 00 00 00
key: 02 00 00 00  value: 00 00 00 00 00 00 00 00
key: 03 00 00 00  value: 00 00 00 00 00 00 00 00
key: 04 00 00 00  value: 00 00 00 00 00 00 00 00
key: 05 00 00 00  value: 00 00 00 00 00 00 00 00
key: 06 00 00 00  value: 40 b5 00 00 00 00 00 00
key: 07 00 00 00  value: 00 00 00 00 00 00 00 00
Found 8 elements

만세, 모든 것이 작동합니다. 그런데 지도가 다시 바이트 형식으로 표시된다는 점에 유의하세요. 이는 다음과 같은 사실 때문입니다. libbpf 유형 정보(BTF)를 로드하지 않았습니다. 하지만 이에 대해서는 다음 시간에 더 자세히 이야기하겠습니다.

개발 도구

이 섹션에서는 최소 BPF 개발자 툴킷을 살펴보겠습니다.

일반적으로 BPF 프로그램을 개발하는 데 특별한 것은 필요하지 않습니다. BPF는 괜찮은 배포 커널에서 실행되며 프로그램은 다음을 사용하여 구축됩니다. clang, 패키지에서 제공될 수 있습니다. 그러나 BPF가 개발 중이기 때문에 커널과 도구가 지속적으로 변경되고 있습니다. 2019년부터 구식 방법을 사용하여 BPF 프로그램을 작성하지 않으려면 컴파일해야 합니다.

• llvm/clang
• pahole
• 그 핵심
• bpftool

(참고로 이 섹션과 기사의 모든 예제는 Debian 10에서 실행되었습니다.)

llvm/clang

BPF는 LLVM과 친화적이며 최근 BPF용 프로그램은 gcc를 사용하여 컴파일할 수 있지만 현재의 모든 개발은 LLVM용으로 수행됩니다. 따라서 우선 현재 버전을 빌드하겠습니다. clang 자식에서 :

$ sudo apt install ninja-build
$ git clone --depth 1 https://github.com/llvm/llvm-project.git
$ mkdir -p llvm-project/llvm/build/install
$ cd llvm-project/llvm/build
$ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" 
                      -DLLVM_ENABLE_PROJECTS="clang" 
                      -DBUILD_SHARED_LIBS=OFF 
                      -DCMAKE_BUILD_TYPE=Release 
                      -DLLVM_BUILD_RUNTIME=OFF
$ time ninja
... много времени спустя
$

이제 모든 것이 올바르게 결합되었는지 확인할 수 있습니다.

$ ./bin/llc --version
LLVM (http://llvm.org/):
  LLVM version 11.0.0git
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver1

  Registered Targets:
    bpf    - BPF (host endian)
    bpfeb  - BPF (big endian)
    bpfel  - BPF (little endian)
    x86    - 32-bit X86: Pentium-Pro and above
    x86-64 - 64-bit X86: EM64T and AMD64

(조립 설명서 clang 내가 가져온 것 bpf_devel_QA.)

방금 만든 프로그램을 설치하지 않고 대신에 프로그램을 추가하기만 하면 됩니다. PATH예 :

export PATH="`pwd`/bin:$PATH"

(이것은 다음에 추가될 수 있습니다. .bashrc 아니면 별도의 파일로. 개인적으로 저는 이런 내용을 추가합니다. ~/bin/activate-llvm.sh 그리고 필요할 때 나는 그것을 한다 . activate-llvm.sh.)

파홀과 BTF

공익 사업 pahole BTF 형식의 디버깅 정보를 생성하기 위해 커널을 빌드할 때 사용됩니다. BTF 기술이 편리하고 사용하고 싶다는 사실 외에는 이 기사에서 BTF 기술의 세부 사항에 대해 자세히 설명하지 않겠습니다. 따라서 커널을 빌드하려면 먼저 빌드하십시오. pahole (없이 pahole 옵션을 사용하면 커널을 빌드할 수 없습니다. CONFIG_DEBUG_INFO_BTF:

$ git clone https://git.kernel.org/pub/scm/devel/pahole/pahole.git
$ cd pahole/
$ sudo apt install cmake
$ mkdir build
$ cd build/
$ cmake -D__LIB=lib ..
$ make
$ sudo make install
$ which pahole
/usr/local/bin/pahole

BPF 실험을 위한 커널

BPF의 가능성을 탐색할 때 나만의 코어를 조립하고 싶습니다. 일반적으로 이것은 배포 커널에서 BPF 프로그램을 컴파일하고 로드할 수 있기 때문에 필요하지 않습니다. 그러나 자체 커널을 사용하면 최신 BPF 기능을 사용할 수 있으며, 이는 기껏해야 몇 달 안에 배포판에 표시됩니다. , 또는 일부 디버깅 도구의 경우에는 가까운 미래에 전혀 패키지되지 않을 것입니다. 또한 자체 핵심으로 인해 코드를 실험하는 것이 중요하다고 느껴집니다.

커널을 빌드하려면 먼저 커널 자체가 필요하고 두 번째로 커널 구성 파일이 필요합니다. BPF를 실험하기 위해 우리는 일반적인 방법을 사용할 수 있습니다 바닐라 커널 또는 개발 커널 중 하나입니다. 역사적으로 BPF 개발은 Linux 네트워킹 커뮤니티 내에서 이루어졌으므로 조만간 모든 변경 사항은 Linux 네트워킹 관리자인 David Miller를 통해 이루어집니다. 성격(편집 또는 새로운 기능)에 따라 네트워크 변경은 두 개의 코어 중 하나에 속합니다. net 또는 net-next. BPF에 대한 변경 사항은 다음과 같은 방식으로 배포됩니다. bpf и bpf-next, 이는 각각 net과 net-next로 풀링됩니다. 자세한 내용은 다음을 참조하세요. bpf_devel_QA и netdev-FAQ. 따라서 귀하의 취향과 테스트 중인 시스템의 안정성 요구 사항에 따라 커널을 선택하십시오(*-next 커널은 나열된 것 중 가장 불안정합니다.)

커널 구성 파일을 관리하는 방법에 대해 설명하는 것은 이 기사의 범위를 벗어납니다. 이 작업을 수행하는 방법을 이미 알고 있다고 가정합니다. 배울 준비가 스스로. 그러나 다음 지침은 작동하는 BPF 지원 시스템을 제공하는 데 어느 정도 충분해야 합니다.

위 커널 중 하나를 다운로드하십시오.

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
$ cd bpf-next

최소한으로 작동하는 커널 구성을 구축합니다.

$ cp /boot/config-`uname -r` .config
$ make localmodconfig

파일에서 BPF 옵션 활성화 .config 자신이 선택한 것(아마도 CONFIG_BPF systemd가 사용하기 때문에 이미 활성화되어 있습니다). 다음은 이 기사에 사용된 커널 옵션 목록입니다.

CONFIG_CGROUP_BPF=y
CONFIG_BPF=y
CONFIG_BPF_LSM=y
CONFIG_BPF_SYSCALL=y
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_BPF_JIT_DEFAULT_ON=y
CONFIG_IPV6_SEG6_BPF=y
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_BPFILTER is not set
CONFIG_NET_CLS_BPF=y
CONFIG_NET_ACT_BPF=y
CONFIG_BPF_JIT=y
CONFIG_BPF_STREAM_PARSER=y
CONFIG_LWTUNNEL_BPF=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_BPF_EVENTS=y
CONFIG_BPF_KPROBE_OVERRIDE=y
CONFIG_DEBUG_INFO_BTF=y

그러면 모듈과 커널을 쉽게 조립하고 설치할 수 있습니다(그런데 새로 조립한 커널을 사용하여 커널을 조립할 수 있습니다). clang추가하여 CC=clang):

$ make -s -j $(getconf _NPROCESSORS_ONLN)
$ sudo make modules_install
$ sudo make install

그리고 새 커널로 재부팅합니다(저는 이것을 위해 사용합니다) kexec 패키지에서 kexec-tools):

v=5.8.0-rc6+ # если вы пересобираете текущее ядро, то можно делать v=`uname -r`
sudo kexec -l -t bzImage /boot/vmlinuz-$v --initrd=/boot/initrd.img-$v --reuse-cmdline &&
sudo kexec -e

bpftool

이 기사에서 가장 일반적으로 사용되는 유틸리티는 다음과 같습니다. bpftool, Linux 커널의 일부로 제공됩니다. BPF 개발자를 위해 BPF 개발자가 작성하고 유지 관리하며 프로그램 로드, 지도 생성 및 편집, BPF 생태계 수명 탐색 등 모든 유형의 BPF 개체를 관리하는 데 사용할 수 있습니다. 매뉴얼 페이지에 대한 소스 코드 형태의 문서를 찾을 수 있습니다. 핵심에 또는 이미 컴파일된 경우 네트워크에서.

이 글을 쓰는 시점에서 bpftool RHEL, Fedora 및 Ubuntu에 대해서만 기성품으로 제공됩니다(예를 들어 다음을 참조하세요). 이 스레드포장의 끝나지 않은 이야기를 전하는 , bpftool 데비안에서). 하지만 이미 커널을 구축했다면, 커널을 구축하세요. bpftool 파이만큼 쉽다:

$ cd ${linux}/tools/bpf/bpftool
# ... пропишите пути к последнему clang, как рассказано выше
$ make -s

Auto-detecting system features:
...                        libbfd: [ on  ]
...        disassembler-four-args: [ on  ]
...                          zlib: [ on  ]
...                        libcap: [ on  ]
...               clang-bpf-co-re: [ on  ]

Auto-detecting system features:
...                        libelf: [ on  ]
...                          zlib: [ on  ]
...                           bpf: [ on  ]

$

(여기 ${linux} - 이것은 커널 디렉토리입니다.) 이 명령을 실행한 후 bpftool 디렉토리에 수집됩니다 ${linux}/tools/bpf/bpftool 경로에 추가할 수 있습니다(우선 사용자에게 root) 또는 다음으로 복사하세요. /usr/local/sbin.

수집 bpftool 후자를 사용하는 것이 가장 좋습니다 clang, 위에서 설명한 대로 조립하고 올바르게 조립되었는지 확인합니다. 예를 들어 다음 명령을 사용합니다.

$ sudo bpftool feature probe kernel
Scanning system configuration...
bpf() syscall for unprivileged users is enabled
JIT compiler is enabled
JIT compiler hardening is disabled
JIT compiler kallsyms exports are enabled for root
...

커널에서 어떤 BPF 기능이 활성화되어 있는지 보여줍니다.

그런데 이전 명령은 다음과 같이 실행할 수 있습니다.

# bpftool f p k

이는 패키지의 유틸리티와 유사하게 수행됩니다. iproute2, 예를 들어 다음과 같이 말할 수 있습니다. ip a s eth0 대신 ip addr show dev eth0.

결론

BPF를 사용하면 벼룩을 효과적으로 측정하고 코어의 기능을 즉각적으로 변경할 수 있습니다. 이 시스템은 UNIX의 최고 전통에 따라 매우 성공적인 것으로 판명되었습니다. 커널을 (재)프로그래밍할 수 있는 간단한 메커니즘을 통해 수많은 사람과 조직이 실험을 할 수 있었습니다. 그리고 BPF 인프라 자체의 개발과 실험이 아직 완료되지 않았지만 시스템에는 이미 신뢰할 수 있고 가장 중요하게는 효과적인 비즈니스 논리를 구축할 수 있는 안정적인 ABI가 있습니다.

제 생각에는 이 기술이 한편으로는 다음과 같은 이유로 매우 대중화되었다는 점에 주목하고 싶습니다. 놀다 (기계의 구조는 어느 날 저녁에 어느 정도 이해될 수 있습니다.) 다른 한편으로는 등장하기 전에는 (아름답게) 해결할 수 없었던 문제를 해결하는 것입니다. 이 두 가지 구성 요소가 결합되어 사람들은 실험하고 꿈을 꾸게 되며, 이는 점점 더 혁신적인 솔루션의 출현으로 이어집니다.

이 기사는 특별히 짧지는 않지만 BPF의 세계에 대한 소개일 뿐이며 "고급" 기능과 아키텍처의 중요한 부분을 설명하지 않습니다. 앞으로의 계획은 다음과 같습니다. 다음 기사에서는 BPF 프로그램 유형(5.8 커널에서 지원되는 프로그램 유형 30개)에 대한 개요를 설명하고 마지막으로 커널 추적 프로그램을 사용하여 실제 BPF 애플리케이션을 작성하는 방법을 살펴보겠습니다. 예를 들어 BPF 아키텍처에 대한 보다 심층적인 과정을 진행한 다음 BPF 네트워킹 및 보안 애플리케이션의 예를 살펴보겠습니다.

이 시리즈의 이전 기사

1. 어린 아이들을 위한 BPF, 파트 XNUMX: 클래식 BPF

연결

1. BPF 및 XDP 참조 가이드 — cilium의 BPF에 대한 문서, 더 정확하게는 BPF의 창시자이자 유지관리자 중 한 명인 Daniel Borkman의 문서입니다. 이것은 다니엘이 자신이 쓰고 있는 내용을 정확히 알고 거기에 실수가 없다는 점에서 다른 설명과 다른 최초의 진지한 설명 중 하나입니다. 특히 이 문서에서는 잘 알려진 유틸리티를 사용하여 XDP 및 TC 유형의 BPF 프로그램으로 작업하는 방법을 설명합니다. ip 패키지에서 iproute2.

2. 문서/네트워킹/filter.txt — 클래식 및 확장 BPF에 대한 문서가 포함된 원본 파일입니다. 어셈블리 언어와 기술적인 아키텍처 세부 사항을 자세히 알아보고 싶다면 읽어보면 좋습니다.

3. Facebook의 BPF 관련 블로그. 거의 업데이트되지 않지만 Alexei Starovoitov(eBPF 작성자)와 Andrii Nakryiko(관리자)가 거기에 쓴 것처럼 적절하게 업데이트됩니다. libbpf).

4. bpftool의 비밀. bpftool 사용의 예와 비밀을 담은 Quentin Monnet의 재미있는 트위터 스레드입니다.

5. BPF 살펴보기: 읽기 자료 목록. Quentin Monnet의 BPF 문서에 대한 대규모(그리고 여전히 유지 관리되는) 링크 목록입니다.

출처 : habr.com