אם אתם מודאגים לגבי שלמות המערכת שלכם, dm-verity הוא אחד החלקים המרכזיים במערכת האקולוגית של לינוקס. לאתחול בטוח ולזיהוי שיבושים באחסון. מקורו כחלק ממפה ההתקנים של הליבה וכעת הוא הבסיס לאתחול מאומת באנדרואיד, OpenWrt והפצות המחפשות אבטחה משופרת.
רחוק מלהיות מושג מופשט, dm-verity מוגדר ונמצא בשימוש עם כלים אמיתיים כמו veritysetup ו- systemd-veritysetupהוא מאמת בלוקים תוך כדי תנועה באמצעות עצי גיבוב ויכול להגיב לשחיתות באמצעות מדיניות הנעות בין רישום האירוע ועד לאתחול או קריסת המערכת. בואו נבחן מקרוב, מבלי להשאיר קצוות פתוחים.
מה זה dm-verity ולמה זה אולי אכפת לך
dm-verity הוא יעד של מיפוי התקנים בליבת ה-device. מאמת את שלמות התקן הבלוק בזמן קריאת הנתוניםזה עובד על ידי חישוב ואימות של גיבוב (hash) של כל בלוק (בדרך כלל 4K) מול עץ גיבוב מחושב מראש, בדרך כלל באמצעות SHA-256.
עיצוב זה מאפשר לא ניתן לשנות קבצים באופן שקט בין אתחול מחדש או במהלך ההפעלהזהו מפתח להרחבת שרשרת האמון של האתחול למערכת ההפעלה, הגבלת התמדה של תוכנות זדוניות, חיזוק מדיניות אבטחה והבטחת מנגנוני הצפנה ומנגנוני MAC במהלך האתחול.
באנדרואיד (מאז 4.4) ובלינוקס באופן כללי, אמון מעוגן בשורש העץ, אשר חתום ומאומת באמצעות מפתח ציבורי הממוקם במיקום מוגן (למשל, במחיצת האתחול או ב-UKI חתום על ידי אתחול מאובטח). פריצת כל בלוק תדרוש פריצת ה-hash הקריפטוגרפי הבסיסי.
אימות מתבצע באמצעות בלוק ולפי דרישה: תוספת ההשהיה מינימלית בהשוואה לעלות הקלט/פלטאם בדיקה נכשלת, הליבה מחזירה שגיאת קלט/פלט ומערכת הקבצים נראית פגומה, דבר הצפוי כאשר הנתונים אינם אמינים. אפליקציות יכולות להחליט אם להמשיך או לא על סמך סבילות התקלות שלהן.
כיצד עץ האימות פועל באופן פנימי
עץ האימות בנוי בשכבות. שכבה 0 היא הנתונים הגולמיים מהמכשיר, המחולקים לבלוקים של 4Kגיבוב SHA-256 (מלח) מחושב עבור כל בלוק. לאחר מכן, הגיבובים הללו משורשרים ליצירת שכבה 1. לאחר מכן, שכבה 1 מקובצת לבלוקים ומגיבוב מחדש ליצירת שכבה 2, וכן הלאה עד שהכל מתאים לבלוק יחיד: בלוק זה, כאשר הוא עובר גיבוב, מייצר את הגיבוב הבסיסי.
אם שכבה כלשהי לא משלימה בלוק בדיוק, הוא מרופד באפסים עד שהוא מגיע ל-4K כדי למנוע אי-בהירות. הגודל הכולל של העץ תלוי בגודל המחיצה הנבדקת; בפועל, זה בדרך כלל פחות מ-30 מגה-בייט עבור מחיצות מערכת טיפוסיות.
התהליך הכללי הוא: בחר מלח אקראי, גיבוב ל-4K, חשב את SHA-256 עם מלח לכל בלוק, משרשרת ליצירת רמות, ממלאת את גבול הבלוק באפסים, וחוזרת על הפעולה עם הרמה הקודמת עד שנותר גיבוב שורש יחיד. גיבוב שורש זה, יחד עם המלח בו נעשה שימוש, מזין את טבלת dm-verity ואת החתימה.
גרסאות פורמט דיסק ואלגוריתם
לפורמט של בלוקי גיבוב בדיסק יש גרסה. גרסה 0 הייתה הגרסה המקורית ששימשה במערכת ההפעלה Chromium OSהמלח נוסף בסוף תהליך הגיבוב, העיכולים מאוחסנים ברציפות, ושאר הבלוק מרופד באפסים.
La גרסה 1 מומלצת למכשירים חדשיםהמלח מוסיף לגיבוב, וכל תקציר מרופד באפסים עד חזקה של שתיים, מה שמשפר את היישור והחוסן. טבלת dm-verity מציינת גם את האלגוריתם (למשל, sha1 או sha256), אם כי עבור אבטחה נוכחית, נעשה שימוש ב-sha256.
טבלת dm-verity ופרמטרים חיוניים
טבלת היעד dm-verity מתארת היכן נמצאים הנתונים, היכן נמצא עץ ה-hash, וכיצד לאמתשדות טבלה אופייניים:
- dev: מכשיר עם הנתונים שיש לאמת (סוג נתיב /dev/sdXN או גדול יותר:lesser).
- hash_dev: מכשיר עם עץ הגיבוב (יכול להיות זהה; אם כן, hash_start חייב להיות מחוץ לטווח המסומן).
- גודל_בלוק_נתוניםגודל בלוק נתונים בבתים (לדוגמה 4096).
- גודל_בלוק_hashגודל בלוק ה-hash בבתים.
- מספר_בלוקי_נתוניםמספר בלוקי נתונים הניתנים לאימות.
- hash_start_block: קיזוז (בבלוקים בגודל hash_block_size) לבלוק השורש של העץ.
- אַלגוֹרִיתְםאלגוריתם גיבוב (למשל sha256).
- לְעַכֵּלקידוד הקסדצימלי של ה-hash של בלוק השורש (כולל salt בהתאם לגרסת הפורמט); ערך זה הוא זה שיש לסמוך עליו.
- מלחמלח הקסדצימלי.
בנוסף, ישנם פרמטרים אופציונליים שימושי מאוד להתאמת התנהגות:
- התעלם_משחיתותרושם בלוקים פגומים, אך מאפשר לקריאה להמשיך.
- הפעלה_מאחר_שחיתות: הפעלה מחדש בעת זיהוי נזק (לא תואם ל-ignore_corruption ודורש תמיכה במרחב המשתמש כדי למנוע לולאות).
- פאניקה משחיתות: : גורם לפאניקה בעת גילוי נזק (לא תואם לגרסאות קודמות).
- הפעלה_ב_שגיאה y panic_on_errorאותן תגובות אך עבור שגיאות קלט/פלט.
- התעלם_מאפס_בלוקים: לא בודק בלוקים שצפויים להיות אפסים ומחזיר אפסים.
- use_fec_from_device + fec_roots + fec_blocks + fec_start: אפשר ל-Reed–Solomon (FEC) לשחזר נתונים כאשר האימות נכשל; אזורי הנתונים, הגיבוב וה-FEC לא חייבים להיות חופפים, וגדלי הבלוקים חייבים להתאים.
- בדיקה_לכל_הכי_פעם_פעם: בודק כל בלוק נתונים רק בפעם הראשונה שהוא נקרא (מפחית תקורה על חשבון אבטחה במתקפות חיות).
- root_hash_sig_key_descהפניה למפתח בטבעת המפתחות כדי לאמת חתימת PKCS7 של גיבוב הבסיס בעת יצירת המיפוי (דורש תצורת ליבה מתאימה וטבעות מפתחות מהימנות).
- try_verify_in_taskletאם קוד ה-hash מאוחסן במטמון וגודל הקלט/פלט מאפשר זאת, בודקים את החצי התחתון כדי להפחית את ההשהיה; מותאם באמצעות /sys/module/dm_verity/parameters/use_bh_bytes לכל מחלקת קלט/פלט.
חתימה, מטא-דאטה ועיגון אמון
כדי ש-dm-verity יהיה אמין, יש לסמוך על ה-hash של הבסיס ובדרך כלל לחתום עליו.באנדרואיד הקלאסי, מפתח ציבורי כלול במחיצת האתחול, אשר מאומת חיצונית על ידי היצרן; הוא מאמת את חתימת ה-hash של הבסיס ומבטיח שמחיצת המערכת לא שונתה.
מטא-דאטה של Verity מוסיפה מבנה ובקרת גרסאות. בלוק המטא-דאטה כולל מספר קסם 0xb001b001 (בתים b0 01 b0 01), גרסה (נכון לעכשיו 0), חתימת הטבלה ב-PKCS1.5 (בדרך כלל 256 בתים עבור RSA-2048), אורך הטבלה, הטבלה עצמה ואפס ריפוד עד 32K.
ביישומי אנדרואיד, האימות מסתמך על fs_mgr ו-fstab: הוספת סימן ביקורת לערך המתאים והצבת המפתח ב-/boot/verity_key. אם המספר הקסם אינו במקום בו הוא אמור להיות, האימות נעצר כדי למנוע בדיקת הדבר הלא נכון.
תחילת הפעולה אומתה
ההגנה נמצאת בליבת הגרעין: אם נפרץ לפני שהליבה מאותחלת, התוקף שומר על השליטהזו הסיבה שיצרנים בדרך כלל מאמתים בקפדנות כל שלב: מפתח שנצרב במכשיר מאמת את טוען האתחול הראשון, אשר מאמת את הבא, את טוען האתחול של האפליקציה, ולבסוף, את הליבה.
לאחר אימות הליבה, dm-verity מופעל בעת הרכבת התקן הבלוק המאומתבמקום לבצע hashing של כל המכשיר (מה שיהיה איטי ובזבז אנרגיה), הוא מאומת בלוק אחר בלוק תוך כדי גישה אליו. כשל גורם לשגיאת קלט/פלט, ושירותים ואפליקציות מגיבים בהתאם לסבילות שלהם: או להמשיך ללא הנתונים או לקרוס לחלוטין.
תיקון שגיאות קדימה (FEC)
מאז אנדרואיד 7.0, FEC (ריד-סולומון) משולב עם טכניקות שזירה כדי להפחית את השטח ולהגדיל את היכולת לשחזר בלוקים פגומים. זה עובד בשילוב עם dm-verity: אם בדיקה נכשלת, תת-המערכת יכולה לנסות לתקן אותה לפני שתכריז עליה כבלתי ניתנת לשחזור.
ביצועים ואופטימיזציה
כדי להפחית את ההשפעה: הפעלת האצת SHA-2 על ידי NEON ב-ARMv7 והרחבות SHA-2 ב-ARMv8 מהליבה. התאם את פרמטרי הקריאה מראש והפרמטרי הקריאה מראש (prefetch_cluster) עבור החומרה שלך; אימות לפי בלוק בדרך כלל מוסיף מעט לעלות הקלט/פלט, אך הגדרות אלו עושות את ההבדל.
תחילת העבודה עם לינוקס (systemd, veritysetup) ואנדרואיד
בלינוקס מודרני עם systemd, dm-verity מאפשר שרת root מאומת לקריאה בלבד באמצעות veritysetup (חלק מ-cryptsetup), systemd-veritysetup.generator ו- systemd-veritysetup@.service. מומלץ לכלול אתחול מאובטח ו-UKI חתום (תמונת ליבה מאוחדת), למרות שהם אינם חובה לחלוטין.
הכנה וחלוקה מומלצת
חלק ממערכת פונקציונלית ומותאמת. שמור נפח עבור עץ הגיבוב (8-10% מגודל ה-root בדרך כלל מספיקים) ושקול להפריד בין /home ו-/var אם אתה צריך לכתוב. סכמה אופיינית כוללת: ESP (עבור טוען האתחול), XBOOTLDR (עבור UKIs), root (עם או בלי הצפנה), מחיצת VERITY, ובאופן אופציונלי /home ו-/var.
בתור שורש, EROFS היא אלטרנטיבה מעניינת מאוד ל-ext4 או squashfs.זהו תוכנה לקריאה בלבד, עם ביצועים טובים מאוד על כונן פלאש/SSD, דחיסת lz4 כברירת מחדל, ונמצאת בשימוש נרחב בטלפונים של אנדרואיד עם dm-verity.
קבצים שחייבים להיות ניתנים לכתיבה
עם root ro, חלק מהתוכניות מצפות לכתוב אל /etc או במהלך האתחולניתן להעביר אותו ל-/var/etc וליצור קישור סימבולי לכל דבר שצריך לשנות (למשל, חיבורי NetworkManager ב-/etc/NetworkManager/system-connections). שימו לב ש-systemd-journald דורש ש-/etc/machine-id יתקיים בספריית השורש (לא קישור סימבולי) כדי למנוע פגיעה באתחול מוקדם.
כדי לגלות אילו שינויים בביצוע, השתמש ב-dracut-overlayroot: מכסה tmpfs מעל הקובץ השורש, וכל מה שנכתב מופיע בקובץ /run/overlayroot/u. הוסף את המודול לקובץ /usr/lib/dracut/modules.d/, כלול את overlayroot בקובץ dracut, והגדר את overlayroot=1 בשורת הליבה; כך תראה לאן להעביר לקובץ /var.
דוגמאות שימושיות: pacman ו-NetworkManager
בארצ', זה נוח העבר את מסד הנתונים של Pacman אל /usr/lib/pacman כך שקובץ ה-rootfs תמיד משקף את החבילות המותקנות. לאחר מכן, הפנה את המטמון אל /var/lib/pacman וקשר אותו. כדי לשנות את רשימת המראות מבלי לגעת בקובץ ה-root, העבר אותו אל /var/etc וקשר אותו בכל מקרה.
עם מנהל הרשת, העבר את חיבורי המערכת אל /var/etc/NetworkManager וקישור מ-/etc/NetworkManager/system-connections. פעולה זו שומרת על ה-root בלתי ניתן לשינוי ועל התצורה פעילה במקום שבו היא אמורה להיות ניתנת לכתיבה.
בניית אמת ובדיקה
ממצב חי, עם הכל מושלם ומותקן ב-RO, צור את העץ והרוטהש עם פורמט veritysetup: בעת ההפעלה, הוא מדפיס את שורת ה-Root Hash, אותה ניתן לשמור בקובץ roothash.txt. הפעל אותו לבדיקה עם veritysetup, פתח את root-device root verity-device $(cat roothash.txt) וטען את /dev/mapper/root.
אם אתה מעדיף, ראשית יוצר את העץ לקובץ (verity.bin) ולאחר מכן כתוב אותו למחיצת VERITY. הקבוצה המתקבלת היא: תמונת שורש, עץ Verity, וגיבוב השורש שתצמיד בעת האתחול.
הגדר את שורת הליבה
הוסף את הפרמטרים הבאים: systemd.verity=1, roothash=contents_of_roothash.txt, systemd.verity_root_data=ROOT-PATH (לדוגמה, LABEL=OS), ו- systemd.verity_root_hash=VERITY-PATH (לדוגמה, LABEL=VERITY). הגדר את systemd.verity_root_options ל-restart-on-corruption או ל-panic-on-corruption עבור מדיניות מחמירה.
אפשרויות מומלצות נוספות: ro (אם אינך משתמש/ת ב-EROFS/squashfs), rd.emergency=אתחול מחדש y rd.shell=0 (למנוע פגזים לא מורשים אם האתחול נכשל), ו סגר = סודיות כדי להגן על זיכרון הליבה מפני גישה.
מחיצות נוספות עם Verity
לא רק השורש: ניתן להגדיר מיפויים אחרים ב-/etc/veritytab ו- systemd-veritysetup@.service ירכיב אותם בעת האתחול. זכרו: קל יותר לטעון RW מחיצה שאינה root, ומשתמש root יכול להשבית את Verity במחיצות אלו, כך שערך האבטחה שם נמוך יותר.
אבטחה: אתחול מאובטח, UKI ומודולים חתומים
dm-verity אינו פתרון קסם. חתום על ה-UKI והפעל אתחול מאובטח עם המפתחות שלך כדי למנוע מכל אחד לעקוף את kernel/initramfs/cmdline (הכולל את ה-root hash). כלים כמו sbupdate-git או sbctl עוזרים לשמור על תמונות חתומות ועל שרשרת האתחול שלמה.
אם תפעילו נעילת ליבה או אימות חתימת מודול, יש לחתום על מודולי DKMS או מודולים מחוץ לעץ או שהם לא ייטענו. שקול ליבה מותאמת אישית עם תמיכה בחתימה עבור הצינור שלך (ראה מודולי ליבה חתומים).
הצפנה, TPM ומדידה
dm-verity מגנה על שלמות, אי-סודיותניתן להשאיר את קובץ ה-root לא מוצפן אם הוא אינו מכיל סודות ושרשרת האתחול מוגנת. אם אתם משתמשים בקבצי מפתח מקובץ ה-root כדי לפתוח אמצעי אחסון אחרים, מומלץ להצפין אותו.
עם TPM 2.0, systemd-cryptenroll מאפשר קשירת מפתחות ל-PCRs 0,1,5,7 (קושחה, אפשרויות, GPT, סטטוס אתחול מאובטח). הוסף rd.luks.options=LUKS_UUID=tpm2-device=auto וודא שאתה כולל תמיכה ב-TPM2 בקובץ initramfs. systemd-boot מודד את kernel.efi ב-PCR4, שימושי לביטול מפתחות אם ה-UKI או שורת ה-cmd שלו משתנים.
עדכונים ומודלים של פריסה
שורש מאומת לקריאה בלבד זה לא מתעדכן עם מנהל החבילות בצורה המסורתיתהאידיאל הוא לבנות תמונות חדשות בעזרת כלים כמו פרויקט יוקטו ולפרסם אותם. ל-systemd יש את systemd-sysupdate ו-systemd-repart להורדה ופלאש של תמונות בצורה יעילה.
אסטרטגיה נוספת היא סכימת A/Bאתה שומר על שני שורשים ושני אמיתות. העתק את השורש הפעיל לשורש הלא פעיל, החל שינויים ובצע מחדש את האמיתות. חזור לאתחול הבא. אם אתה משתמש ב-UKI, זכור לעדכן את ה-hash של השורש בשורת ה-cmd או לבנות מחדש את ה-UKI החתום.
להתמדה אופציונלית, השתמש ב-OverlayFS על הקובץ הבסיסי המאומת עם upper ב-tmpfs או בדיסק. ניתן גם להעביר systemd.volatile=overlay לצורך שמירה זמנית. Flatpak מאפשר להתקין בקלות אפליקציות ב-/var וב-/home מבלי לגעת ב-/.
ישנן חבילות אוטומטיות (למשל verity-squash-root ב-AUR) שבונות שורש squashfs ו- חתום על ה-roothash עם kernel ו-initramfs, המאפשר לך לבחור בין מצב קבוע או זמני לבין שימור קבצי ה-rootf העדכניים ביותר כגיבוי. הערה: הוספת קבועה לקובץ root מאומת כוללת מקרי שימוש צרים; נסה לשמור נתוני אפליקציה במחיצות נפרדות.
אנדרואיד: מערכת כשורש, AVB ושכבות-על של ספקים
מאז אנדרואיד 10, RootFS מפסיק לפעול על דיסק ה-RAM ומשתלב עם system.img. (system-as-root). מכשירים המופעלים עם אנדרואיד 10 תמיד משתמשים בסכימה זו ודורשים RAMdisk עבור dm-linear. BOARD_BUILD_SYSTEM_ROOT_IMAGE מוגדר כ-false בבנייה זו כדי להבחין בין שימוש ב-RAMdisk לבין הפעלה ישירה של system.img.
אנדרואיד 10 משלב מחיצות דינמיות ואתחול בשלב ראשון אשר מפעיל את מחיצת המערכת הלוגית; הליבה כבר לא מעלה אותה ישירות. OTAs למערכת בלבד דורשים עיצוב של מערכת כשורש, שהוא חובה במכשירי אנדרואיד 10.
בשום A/B, שמור את ההתאוששות בנפרד מהאתחולבניגוד ל-A/B, אין גיבוי boot_a/boot_b, כך שהסרת recovery בגרסה שאינה A/B עלולה להשאיר אותך ללא מצב שחזור אם עדכון אתחול נכשל.
הליבה מתחברת לקובץ system.img אל /converity דרך שני נתיבים: vboot 1.0 (תיקונים עבור הליבה לניתוח מטא-דאטה של אנדרואיד ב-/system ולגזירת פרמטרים של dm-verity; שורת ה-cmd כוללת root=/dev/dm-0, skip_initramfs ו-init=/init עם dm=…) או vboot 2.0/AVB, שבו טוען האתחול משלב את libavb, קורא את מתאר ה-hashtree (ב-vbmeta או system), בונה את הפרמטרים ומעביר אותם לליבה ב-cmdline, עם תמיכה ב-FEC ודגלים כמו restart_on_corruption.
עם מערכת-כשורש, אל תשתמש ב-BOARD_ROOT_EXTRA_FOLDERS עבור תיקיות שורש ספציפיות למכשיר: אלה ייעלמו בעת עדכון GSI. הגדירו mounts ספציפיים תחת /mnt/vendor/ , אשר fs_mgr יוצר באופן אוטומטי, ומפנה אליהם ב-fstab של עץ המכשירים.
אנדרואיד מאפשרת שכבת ספק מ-/product/vendor_overlay/init יטען ב-/vendor את תת-הספריות שעומדות בדרישות ההקשר של SELinux ובקיומו של /vendor/ דורש CONFIG_OVERLAY_FS=yy, בליבות ישנות יותר, את התיקון override_creds=off.
יישום טיפוסי: מתקין קבצים מורכבים מראש במכשיר/ / /overlay_ספק/, הוסף אותם ל-PRODUCT_COPY_FILES עם find-copy-subdir-files לקובץ $(TARGET_COPY_OUT_PRODUCT)/vendor_overlay, הגדירו הקשרים ב-file_contexts עבור etc ו-app (למשל, vendor_configs_file ו-vendor_app_file) ואפשרו mounton על הקשרים אלה ב-init.te. בדוק עם atest vfs_mgr_vendor_overlay_test ב-userdebug.
פתרון בעיות: הודעת פגיעה ב-dm-verity באנדרואיד
במכשירים עם חריצי A/B, שנה חריצים או הבזק של vbmeta/boot ללא עקביות של roothash ייתכן שזה יפעיל את האזהרה: dm-verity corruption, your device is untrusted. פקודות כמו fastboot flash –disable-verity –disable-verification vbmeta vbmeta.img מבטלות את האימות, אך משאירות את המערכת ללא כל ערובה לשלמות.
חלק ממנהלי האתחול תומכים אתחול מהיר של יצרן הציוד המקורי (oem) disable_dm_verity וההפך ממנו, enable_dm_verity. זה עובד על דגמים מסוימים, אבל לא על אחרים; וייתכן שזה ידרוש ליבה/מג'יק עם דגלים מותאמים. השימוש על אחריותך בלבד: דרך הפעולה הנבונה היא יישור boot, vbmeta ו-system, חתום או יוצר מחדש את העץ וודא ש-root hash הצפוי תואם לזה שתצורתו נקבעה.
אם לאחר האזהרה ניתן להמשיך ללחוץ על כפתור ההפעלה, המערכת תופעל, אך אין לך יותר שרשרת אמון שלמהכדי להסיר את ההודעה מבלי להתפשר על האבטחה, יש לשחזר את התמונות החתומות המקוריות או לבנות מחדש/לאמת את vbmeta עם ה-hashtree הנכון, במקום להשבית את verity.
פלטפורמות i.MX ו-OpenWrt
ב-i.MX6 (למשל sabresd), הגדר את הליבה עם תמיכה ב-DM_VERITY וב-FEC, צור את העץ עם veritysetup, אחסן את ה-root hash בצורה מאובטחת, והעביר את הפרמטרים המתאימים בשורת cmd או שלב דרך initramfs עם systemd-veritysetup. אם אינך משתמש ב-dm-crypt, אינך זקוק ל-CAAM עבור verity; הדגש הוא על שלמות.
ב-OpenWrt וב- מערכות לינוקס משובצות עם OpenEmbedded, ישנם מאמצים לשלב את dm-verity ו-SELinux (עבודות Bootlin עודכנו במטרה לשלב תמיכה). זוהי התאמה טבעית: נתבים וציוד רשת נהנים מרוט בלתי ניתן לשינוי, מאומת ומוקשר ב-MAC.
בנייה ידנית של עץ ומטא-דאטה (תצוגה מפורטת)
cryptsetup יכול לייצר עבורך את העץ, אך אם אתה מעדיף להבין את הפורמט, הגדרת שורת הטבלה הקומפקטית כוללת: שם מיפוי, התקן נתונים, גדלי בלוקי נתונים וגיבוב, גודל תמונה בבלוקים, מיקום hash_start (תמונת בלוק + 8 אם משורשר), גיבוב שורש ו-salt. לאחר יצירת השכבות המשורשרות (מלמעלה למטה, לא כולל שכבה 0), כותבים את העץ לדיסק.
כדי לארוז הכל, חבר את טבלת dm-verity, חתום עליה (אופייני ל-RSA-2048) וקבץ חתימה+טבלת מטא-נתונים עם כותרת גרסה ומספר קסם. לאחר מכן, היא משרשרת את תמונת המערכת, מטא-נתונים של verity ועץ ה-hash. ב-fstab, היא מסמנת את fs_mgr כ-verify וממקמת את המפתח הציבורי ב-/boot/verity_key כדי לאמת את החתימה.
אופטימיזציה עם האצת SHA-2 עבור המעבד שלך ולהתאים את read-ahead/prefetch_cluster. בחומרת ARM, הרחבות NEON SHA-2 (ARMv7) ו-SHA-2 (ARMv8) מפחיתות משמעותית את תקורת האימות.
בכל פריסה, זכרו ש יש להגן על ערך ה-hash של הבסיסבין אם הוקמפל לתוך UKI חתום, לתוך מחיצת האתחול החתומה, או אומת על ידי טוען האתחול באמצעות AVB. כל דבר לאחר נקודה זו יורש את האמון הזה.
עם כל האמור לעיל במקום, dm-verity הופך ל בסיס איתן למערכות בלתי משתנות, ניידות ומשובצות, תמיכה בעדכוני טרנזקציות, שכבות תצורה ומודל אבטחה מודרני שמפחית את משטח ההתקפה ומונע התמדה מבלי להתפשר על ביצועים.
