מבוא קצר ל-BPF ו-eBPF

שלום, הבר! ברצוננו להודיע ​​לכם שאנו מכינים ספר ליציאתו".יכולת תצפית של לינוקס עם BPF".

מכיוון שהמכונה הוירטואלית BPF ממשיכה להתפתח ונמצאת בשימוש פעיל בפועל, תרגמנו עבורכם מאמר המתאר את היכולות העיקריות שלה ואת מצבה הנוכחי.

בשנים האחרונות, כלי תכנות וטכניקות הפכו פופולריים יותר ויותר כדי לפצות על המגבלות של ליבת לינוקס במקרים בהם נדרש עיבוד מנות בעל ביצועים גבוהים. אחת הטכניקות הפופולריות ביותר מסוג זה נקראת מעקף ליבה (מעקף ליבה) ומאפשר, תוך עקיפת שכבת רשת הקרנל, לבצע את כל עיבוד המנות ממרחב המשתמש. עקיפת הקרנל כרוכה גם בשליטה בכרטיס הרשת מ שטח משתמש. במילים אחרות, כשעובדים עם כרטיס רשת, אנחנו מסתמכים על הדרייבר שטח משתמש.

על ידי העברת שליטה מלאה על כרטיס הרשת לתוכנית מרחב משתמש, אנו מצמצמים את תקורה של הליבה (מיתוג הקשר, עיבוד שכבות רשת, פסיקות וכו'), וזה די חשוב כאשר פועל במהירויות של 10Gb/s ומעלה. מעקף ליבה בתוספת שילוב של תכונות אחרות (עיבוד אצווה) וכוונון ביצועים זהיר (חשבונאות NUMA, בידוד מעבד, וכו') תואמים את היסודות של עיבוד רשת בעל ביצועים גבוהים במרחב המשתמש. אולי דוגמה למופת לגישה החדשה הזו לעיבוד מנות היא DPDK מאת אינטל (ערכת פיתוח מטוסי נתונים), למרות שקיימים כלים וטכניקות ידועות אחרות, כולל ה-VPP של סיסקו (עיבוד מנות וקטור), Netmap וכמובן, סנק.

לארגון אינטראקציות רשת במרחב המשתמש יש מספר חסרונות:

• ליבת מערכת ההפעלה היא שכבת הפשטה עבור משאבי חומרה. מכיוון שתוכניות מרחב משתמש צריכות לנהל את המשאבים שלהן ישירות, עליהן גם לנהל את החומרה שלהן. זה אומר לעתים קרובות שתצטרך לתכנת מנהלי התקנים משלך.
• מכיוון שאנו מוותרים לחלוטין על שטח הליבה, אנו גם מוותרים על כל פונקציונליות הרשת שמספקת הליבה. תוכניות מרחב משתמש חייבות ליישם מחדש תכונות שאולי כבר מסופקות על ידי הליבה או מערכת ההפעלה.
• תוכניות פועלות במצב ארגז חול, מה שמגביל מאוד את האינטראקציה ביניהן ומונע מהן להשתלב עם חלקים אחרים של מערכת ההפעלה.

בעיקרו של דבר, בעת יצירת רשתות במרחב המשתמש, רווחי ביצועים מושגים על ידי העברת עיבוד מנות מהקרנל למרחב המשתמש. XDP עושה בדיוק את ההיפך: הוא מעביר תוכניות רשת ממרחב המשתמש (מסננים, רזולורים, ניתוב וכו') למרחב הקרנל. XDP מאפשר לנו לבצע פונקציית רשת ברגע שחבילה פוגעת בממשק רשת ולפני שהיא מתחילה לעלות לתוך תת-המערכת של רשת הקרנל. כתוצאה מכך, מהירות עיבוד החבילות עולה באופן משמעותי. עם זאת, כיצד הליבה מאפשרת למשתמש להפעיל את התוכניות שלו בחלל הליבה? לפני שנענה על שאלה זו, בואו נסתכל על מה זה BPF.

BPF ו-eBPF

למרות השם המבלבל, BPF (Berkeley Packet Filtering) הוא למעשה דגם של מכונה וירטואלית. מכונה וירטואלית זו תוכננה במקור לטפל בסינון מנות, ומכאן השם.

אחד הכלים המפורסמים ביותר באמצעות BPF הוא tcpdump. בעת לכידת מנות באמצעות tcpdump המשתמש יכול לציין ביטוי לסינון מנות. רק מנות התואמות לביטוי זה ייקלטו. לדוגמה, הביטוי "tcp dst port 80” מתייחס לכל מנות ה-TCP המגיעות ליציאה 80. המהדר יכול לקצר את הביטוי הזה על ידי המרתו ל-BPF bytecode.

$ sudo tcpdump -d "tcp dst port 80"
(000) ldh [12] (001) jeq #0x86dd jt 2 jf 6
(002) ldb [20] (003) jeq #0x6 jt 4 jf 15
(004) ldh [56] (005) jeq #0x50 jt 14 jf 15
(006) jeq #0x800 jt 7 jf 15
(007) ldb [23] (008) jeq #0x6 jt 9 jf 15
(009) ldh [20] (010) jset #0x1fff jt 15 jf 11
(011) ldxb 4*([14]&0xf)
(012) ldh [x + 16] (013) jeq #0x50 jt 14 jf 15
(014) ret #262144
(015) ret #0

זה מה שהתוכנית לעיל עושה בעצם:

• הוראה (000): טוען את החבילה בהיסט 12, כמילה של 16 סיביות, לתוך המצבר. היסט 12 מתאים לסוג האתר של החבילה.
• הוראה (001): משווה את הערך בצובר עם 0x86dd, כלומר, עם ערך האתרטייפ עבור IPv6. אם התוצאה נכונה, מונה התוכנית עובר להוראה (002), ואם לא, אז ל- (006).
• הוראה (006): משווה את הערך ל-0x800 (ערך ethertype עבור IPv4). אם התשובה נכונה, אז התוכנית עוברת אל (007), אם לא, אז אל (015).

וכך הלאה עד שתוכנית סינון המנות תחזיר תוצאה. זה בדרך כלל בוליאנית. החזרת ערך לא אפס (הוראה (014)) פירושה שהחבילה התקבלה, והחזרת ערך אפס (הוראה (015)) פירושה שהחבילה לא התקבלה.

המכונה הוירטואלית BPF וקוד הבתים שלה הוצעו על ידי סטיב מקאן ואן ג'ייקובסון בסוף 1992 כאשר מאמרם פורסם מסנן מנות BSD: ארכיטקטורה חדשה ללכידת מנות ברמת המשתמש, טכנולוגיה זו הוצגה לראשונה בכנס Usenix בחורף 1993.

מכיוון ש-BPF היא מכונה וירטואלית, היא מגדירה את הסביבה שבה תוכניות פועלות. בנוסף לקוד הבתים, הוא גם מגדיר את מודל הזיכרון האצווה (הוראות הטעינה מיושמות באופן מרומז על האצווה), אוגרים (A ו-X; אוגרי מצבר ואינדקס), אחסון זיכרון שריטה ומונה תוכניות מרומז. מעניין לציין שקוד הביטים של BPF עוצב על פי ה-Motorola 6502 ISA. כפי שסטיב מקאן נזכר בשלו דו"ח המליאה ב-Sharkfest '11, הוא הכיר את ה-build 6502 מימי בית הספר התיכון שלו לתכנות ב-Apple II, והידע הזה השפיע על עבודתו בתכנון ה-BPF bytecode.

תמיכת BPF מיושמת בליבת לינוקס בגרסאות v2.5 ומעלה, הנוספה בעיקר על ידי מאמציו של ג'יי שוליסט. קוד BPF נותר ללא שינוי עד 2011, כאשר אריק Dumaset עיצב מחדש את המתורגמן BPF כך שיפעל במצב JIT (מקור: JIT עבור מסנני מנות). לאחר מכן, הקרנל, במקום לפרש BPF bytecode, יוכל להמיר ישירות תוכניות BPF לארכיטקטורת היעד: x86, ARM, MIPS וכו'.

מאוחר יותר, בשנת 2014, אלכסיי Starovoitov הציע מנגנון JIT חדש עבור BPF. למעשה, ה-JIT החדש הזה הפך לארכיטקטורה חדשה מבוססת BPF ונקרא eBPF. אני חושב ששני ה-VMs התקיימו יחד במשך זמן מה, אבל כרגע סינון מנות מיושם על בסיס eBPF. למעשה, בדוגמאות רבות של תיעוד מודרני, BPF מובן כ-eBPF, וה-BPF הקלאסי ידוע היום כ-cBPF.

eBPF מרחיב את המכונה הוירטואלית הקלאסית BPF בכמה דרכים:

• מבוסס על ארכיטקטורות מודרניות של 64 סיביות. eBPF משתמש באוגרים של 64 סיביות ומגדיל את מספר האוגרים הזמינים מ-2 (צבר ו-X) ל-10. eBPF מספק גם קודים נוספים (BPF_MOV, BPF_JNE, BPF_CALL...).
• מנותק מתת המערכת של שכבת הרשת. BPF היה קשור למודל נתוני האצווה. מכיוון שהוא שימש לסינון מנות, הקוד שלו היה ממוקם בתת המערכת המספקת תקשורת רשת. עם זאת, המכונה הוירטואלית eBPF אינה קשורה עוד למודל הנתונים וניתן להשתמש בה לכל מטרה. אז, כעת ניתן לחבר את תוכנית eBPF לנקודת עקיבה או kprobe. זה פותח את הדרך למכשור eBPF, ניתוח ביצועים ומקרי שימוש רבים אחרים בהקשר של תת-מערכות ליבה אחרות. כעת קוד ה-eBPF ממוקם בנתיב שלו: kernel/bpf.
• מאגרי נתונים גלובליים בשם מפות. מפות הן מאגרי מפתח-ערך המאפשרים חילופי נתונים בין מרחב המשתמש למרחב הקרנל. eBPF מספק מספר סוגים של מפות.
• פונקציות משניות. בפרט, כדי לשכתב חבילה, לחשב סכום ביקורת או לשכפל חבילה. פונקציות אלו פועלות בתוך הליבה ואינן תוכניות מרחב משתמש. אתה יכול גם לבצע שיחות מערכת מתוכניות eBPF.
• סיום שיחות. גודל התוכנית ב-eBPF מוגבל ל-4096 בתים. תכונת ה-tail call מאפשרת לתוכנית eBPF להעביר את השליטה לתוכנית eBPF חדשה ובכך לעקוף מגבלה זו (ניתן לקשר עד 32 תוכניות בדרך זו).

eBPF: דוגמה

ישנן מספר דוגמאות עבור eBPF במקורות ליבת לינוקס. הם זמינים ב- samples/bpf/. כדי להרכיב את הדוגמאות האלה, פשוט הזן:

$ sudo make samples/bpf/

אני לא אכתוב דוגמה חדשה עבור eBPF בעצמי, אלא אשתמש באחת הדוגמאות הזמינות ב- samples/bpf/. אני אסתכל על חלקים מסוימים של הקוד ואסביר איך הוא עובד. כדוגמה, בחרתי בתוכנית tracex4.

באופן כללי, כל אחת מהדוגמאות בדוגמאות/bpf/ מורכבת משני קבצים. במקרה הזה:

• tracex4_kern.c, מכיל את קוד המקור שיבוצע בליבה בתור eBPF bytecode.
• tracex4_user.c, מכיל תוכנית ממרחב המשתמש.

במקרה זה, עלינו לבצע קומפילציה tracex4_kern.c לקוד בתים eBPF. כרגע ב gcc אין קצה אחורי עבור eBPF. לְמַרְבֶּה הַמַזָל, clang יכול להוציא eBPF bytecode. Makefile использует clang להידור tracex4_kern.c לקובץ האובייקט.

ציינתי למעלה שאחת התכונות המעניינות ביותר של eBPF הן מפות. tracex4_kern מגדיר מפה אחת:

struct pair {
    u64 val;
    u64 ip;
};  

struct bpf_map_def SEC("maps") my_map = {
    .type = BPF_MAP_TYPE_HASH,
    .key_size = sizeof(long),
    .value_size = sizeof(struct pair),
    .max_entries = 1000000,
};

BPF_MAP_TYPE_HASH הוא אחד מסוגי הכרטיסים הרבים המוצעים על ידי eBPF. במקרה הזה, זה רק חשיש. ייתכן שגם שמת לב למודעה SEC("maps"). SEC הוא מאקרו המשמש ליצירת קטע חדש של קובץ בינארי. בעצם, בדוגמה tracex4_kern שני סעיפים נוספים מוגדרים:

SEC("kprobe/kmem_cache_free")
int bpf_prog1(struct pt_regs *ctx)
{   
    long ptr = PT_REGS_PARM2(ctx);

    bpf_map_delete_elem(&my_map, &ptr); 
    return 0;
}
    
SEC("kretprobe/kmem_cache_alloc_node") 
int bpf_prog2(struct pt_regs *ctx)
{
    long ptr = PT_REGS_RC(ctx);
    long ip = 0;

    // получаем ip-адрес вызывающей стороны kmem_cache_alloc_node() 
    BPF_KRETPROBE_READ_RET_IP(ip, ctx);

    struct pair v = {
        .val = bpf_ktime_get_ns(),
        .ip = ip,
    };
    
    bpf_map_update_elem(&my_map, &ptr, &v, BPF_ANY);
    return 0;
}   

שתי הפונקציות הללו מאפשרות לך למחוק ערך מהמפה (kprobe/kmem_cache_free) והוסיפו ערך חדש למפה (kretprobe/kmem_cache_alloc_node). כל שמות הפונקציות שנכתבו באותיות גדולות תואמים לפקודות מאקרו שהוגדרו ב bpf_helpers.h.

אם אני זורק את הקטעים של קובץ האובייקט, אני אמור לראות שהקטעים החדשים האלה כבר מוגדרים:

$ objdump -h tracex4_kern.o

tracex4_kern.o: file format elf64-little

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000000 0000000000000000 0000000000000000 00000040 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 kprobe/kmem_cache_free 00000048 0000000000000000 0000000000000000 00000040 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
2 kretprobe/kmem_cache_alloc_node 000000c0 0000000000000000 0000000000000000 00000088 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
3 maps 0000001c 0000000000000000 0000000000000000 00000148 2**2
CONTENTS, ALLOC, LOAD, DATA
4 license 00000004 0000000000000000 0000000000000000 00000164 2**0
CONTENTS, ALLOC, LOAD, DATA
5 version 00000004 0000000000000000 0000000000000000 00000168 2**2
CONTENTS, ALLOC, LOAD, DATA
6 .eh_frame 00000050 0000000000000000 0000000000000000 00000170 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA

יש גם tracex4_user.c, תוכנה ראשית. בעיקרון, התוכנית הזו מאזינה לאירועים kmem_cache_alloc_node. כאשר אירוע כזה מתרחש, קוד ה-eBPF המתאים מבוצע. הקוד שומר את תכונת ה-IP של האובייקט במפה, ואז האובייקט עובר בלולאה דרך התוכנית הראשית. דוגמא:

$ sudo ./tracex4
obj 0xffff8d6430f60a00 is 2sec old was allocated at ip ffffffff9891ad90
obj 0xffff8d6062ca5e00 is 23sec old was allocated at ip ffffffff98090e8f
obj 0xffff8d5f80161780 is 6sec old was allocated at ip ffffffff98090e8f

איך תוכנית מרחב משתמש ותוכנית eBPF קשורות? על אתחול tracex4_user.c טוען קובץ אובייקט tracex4_kern.o באמצעות הפונקציה load_bpf_file.

int main(int ac, char **argv)
{
    struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
    char filename[256];
    int i;

    snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);

    if (setrlimit(RLIMIT_MEMLOCK, &r)) {
        perror("setrlimit(RLIMIT_MEMLOCK, RLIM_INFINITY)");
        return 1;
    }

    if (load_bpf_file(filename)) {
        printf("%s", bpf_log_buf);
        return 1;
    }

    for (i = 0; ; i++) {
        print_old_objects(map_fd[1]);
        sleep(1);
    }

    return 0;
}

בעת ביצוע load_bpf_file בדיקות המוגדרות בקובץ eBPF מתווספות /sys/kernel/debug/tracing/kprobe_events. עכשיו אנחנו מקשיבים לאירועים האלה והתוכנית שלנו יכולה לעשות משהו כשהם מתרחשים.

$ sudo cat /sys/kernel/debug/tracing/kprobe_events
p:kprobes/kmem_cache_free kmem_cache_free
r:kprobes/kmem_cache_alloc_node kmem_cache_alloc_node

כל שאר התוכניות ב-example/bpf/ בנויות באופן דומה. הם תמיד מכילים שני קבצים:

• XXX_kern.c: תוכנית eBPF.
• XXX_user.c: תוכנה ראשית.

תוכנית eBPF מזהה מפות ופונקציות הקשורות למקטע. כאשר הקרנל מנפיק אירוע מסוג מסוים (לדוגמה, tracepoint), הפונקציות המאוגדות מבוצעות. הכרטיסים מספקים תקשורת בין תוכנית הקרנל לתוכנית מרחב המשתמש.

מסקנה

מאמר זה דן ב-BPF וב-eBPF במונחים כלליים. אני יודע שיש הרבה מידע ומשאבים על eBPF היום, אז אני אמליץ על כמה משאבים נוספים למחקר נוסף

אני ממליץ לקרוא:

• BPF: המכונה הוירטואלית האוניברסלית בתוך הליבה ג'ונתן קורבט. מבוא ל-BPF וכיצד הוא התפתח ל-eBPF.
• היכרות יסודית עם eBPF ברנדן גרג. מאמר מ-LWN.net. ברנדן מרבה לצייץ על eBPF ומנהל רשימה של משאבים בנושא שלו פוסט בבלוג.
• הערות על BPF ו-eBPF ג'וליה אוונס. הערות על המצגת של Suchakra Sharma "מסנן מנות BSD: ארכיטקטורה חדשה ללכידת מנות ברמת המשתמש". ההערות טובות ובאמת עוזרות לך להבין את השקופיות.
• eBPF, חלק 1: עבר, הווה ועתיד פריס אליס. Longread עם הֶמְשֵׁך, אבל כדאי לקרוא. אחד המאמרים הטובים ביותר שנתקלתי בהם ב-eBPF.

מקור: www.habr.com