إذا كنت قلقًا بشأن سلامة نظامك، dm-verity هو أحد الأجزاء الرئيسية لنظام Linux البيئي للتشغيل الآمن واكتشاف أي تلاعب في وحدة التخزين. نشأ هذا كجزء من مُعيِّن جهاز النواة، وهو الآن أساس التشغيل المُوثَّق في Android وOpenWrt والتوزيعات التي تسعى إلى تحسين الأمان.
بعيدًا عن كونها مفهومًا مجردًا، تم تكوين dm-verity واستخدامه مع أدوات حقيقية مثل veritysetup وsystemd-veritysetupيُتحقق من صحة الكتل تلقائيًا باستخدام أشجار التجزئة، ويمكنه الاستجابة للتلف بسياسات تتراوح من تسجيل الحدث إلى إعادة تشغيل النظام أو تعطله. دعونا نلقي نظرة فاحصة، دون ترك أي تفاصيل غير واضحة.
ما هو dm-verity ولماذا قد يهمك
dm-verity هو هدف تعيين الجهاز في النواة الذي يتحقق من سلامة جهاز الكتلة أثناء قراءة البياناتيعمل عن طريق حساب وتأكيد تجزئات كل كتلة (عادةً 4K) مقابل شجرة تجزئة محسوبة مسبقًا، باستخدام SHA-256 عادةً.
هذا التصميم يسمح بـ لا يمكن تعديل الملفات بصمت بين عمليات إعادة التشغيل أو أثناء التنفيذيعد هذا أمرًا أساسيًا لتوسيع سلسلة الثقة في نظام التشغيل، والحد من استمرار البرامج الضارة، وتعزيز سياسات الأمان، وضمان التشفير وآليات MAC أثناء التمهيد.
على نظام Android (منذ 4.4) ونظام Linux بشكل عام، الثقة راسخة في جذر الشجرة، والذي يُوقّع ويُصدّق بمفتاح عام موجود في موقع محمي (مثلاً، على قسم التمهيد أو في مفتاح UKI موقّع للتمهيد الآمن). يتطلب كسر أي كتلة كسر التجزئة التشفيرية الأساسية.
يتم التحقق عن طريق الحظر وبناءً على الطلب: إن زمن الوصول المضاف ضئيل مقارنة بتكلفة الإدخال/الإخراجفي حال فشل الفحص، تُرجع النواة خطأً في الإدخال/الإخراج، ويبدو نظام الملفات تالفًا، وهو أمر متوقع عندما تكون البيانات غير موثوقة. يمكن للتطبيقات تحديد ما إذا كانت ستستمر أم لا بناءً على قدرتها على تحمل الأخطاء.
كيف تعمل شجرة التحقق داخليًا
تتم بناء شجرة التحقق في طبقات. الطبقة 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 أين توجد البيانات، وأين توجد شجرة التجزئة، وكيفية التحقق منهاحقول الجدول النموذجية:
- ديف: الجهاز الذي يحتوي على البيانات المراد التحقق منها (نوع المسار /dev/sdXN أو أكبر:أقل).
- هاش_ديف: الجهاز الذي يحتوي على شجرة التجزئة (يمكن أن يكون هو نفسه؛ إذا كان الأمر كذلك، فيجب أن يكون hash_start خارج النطاق المحدد).
- حجم كتلة البيانات: حجم كتلة البيانات بالبايتات (على سبيل المثال 4096).
- حجم كتلة التجزئة:حجم كتلة التجزئة بالبايت.
- عدد كتل البيانات:عدد كتل البيانات القابلة للتحقق.
- كتلة بداية التجزئة:الإزاحة (في كتل hash_block_size) إلى كتلة الجذر للشجرة.
- خوارزمية: خوارزمية التجزئة (على سبيل المثال sha256).
- هضم:ترميز سداسي عشري لتجزئة كتلة الجذر (بما في ذلك الملح وفقًا لإصدار التنسيق)؛ هذه القيمة هي التي يجب الوثوق بها.
- ملح: ملح سداسي عشري.
بالإضافة إلى ذلك ، هناك المعلمات الاختيارية مفيد جدًا لتعديل السلوك:
- تجاهل الفساد:يسجل الكتل الفاسدة، لكنه يسمح بمواصلة القراءة.
- إعادة التشغيل عند الفساد:إعادة التشغيل عند اكتشاف الفساد (غير متوافق مع ignore_corruption ويتطلب دعم مساحة المستخدم لتجنب الحلقات).
- الذعر من الفساد: : يسبب الذعر عند اكتشاف الفساد (غير متوافق مع الإصدارات السابقة).
- إعادة تشغيل_على_خطأ y الذعر عند الخطأ: نفس ردود الفعل ولكن بالنسبة لأخطاء الإدخال/الإخراج.
- تجاهل_صفر_كتل: لا يتحقق من الكتل المتوقعة كأصفار ويعيد الأصفار.
- استخدام_fec_من_الجهاز + جذور البراز + كتل البراز + بداية fec:تمكين Reed–Solomon (FEC) لاسترداد البيانات عند فشل التحقق؛ يجب ألا تتداخل مناطق البيانات والتجزئة وFEC، ويجب أن تتطابق أحجام الكتل.
- التحقق مرة واحدة على الأكثر:يتم فحص كل كتلة من البيانات فقط في المرة الأولى التي يتم قراءتها فيها (يقلل التكلفة العامة على حساب الأمان في الهجمات المباشرة).
- وصف مفتاح التجزئة الجذري:إشارة إلى مفتاح في حلقة المفاتيح للتحقق من صحة توقيع PKCS7 لتجزئة الجذر عند إنشاء التعيين (يتطلب تكوين kernel مناسب وحلقات مفاتيح موثوقة).
- حاول التحقق في المهمة:إذا تم تخزين التجزئات مؤقتًا وكان حجم الإدخال/الإخراج يسمح بذلك، يتم التحقق من النصف السفلي لتقليل زمن الوصول؛ يتم تعديله باستخدام /sys/module/dm_verity/parameters/use_bh_bytes لكل فئة إدخال/إخراج.
التوقيع والبيانات الوصفية وترسيخ الثقة
لكي تكون dm-verity موثوقة، يجب أن تكون تجزئة الجذر موثوقة وموقعة عادةًفي نظام Android الكلاسيكي، يتم تضمين مفتاح عام في قسم التمهيد، والذي يتم التحقق منه خارجيًا بواسطة الشركة المصنعة؛ فهو يتحقق من صحة توقيع التجزئة الجذر ويضمن عدم تغيير قسم النظام.
تضيف بيانات Verity التعريفية البنية والتحكم في الإصدار. تتضمن كتلة البيانات الوصفية رقمًا سحريًا 0xb001b001 (بايتات b0 01 b0 01)، الإصدار (0 حاليًا)، توقيع الجدول في PKCS1.5 (عادةً 256 بايت لـ RSA-2048)، طول الجدول، الجدول نفسه والحشو الصفري حتى 32 كيلو بايت.
في تطبيقات Android، يعتمد التحقق على fs_mgr و fstab:إضافة علامة صح إلى الإدخال المقابل ووضع المفتاح في /boot/verity_key. إذا لم يكن الرقم السحري في مكانه الصحيح، يتوقف التحقق لتجنب تحديد العنصر الخطأ.
تم التحقق من بدء العملية
الحماية موجودة في النواة: إذا تم اختراقه قبل تشغيل النواة، يحتفظ المهاجم بالسيطرةلهذا السبب يقوم المصنعون عادةً بالتحقق من صحة كل مرحلة بشكل صارم: يتم إدخال مفتاح إلى الجهاز للتحقق من أداة تحميل التشغيل الأولى، والتي بدورها للتحقق من أداة تحميل التشغيل التالية، أداة تحميل تشغيل التطبيق، وأخيرًا، النواة.
مع التحقق من النواة، يتم تمكين dm-verity عند تحميل جهاز الكتلة الذي تم التحقق منهبدلاً من تجزئة الجهاز بالكامل (مما قد يكون بطيئًا ويهدر الطاقة)، يتم التحقق منه كتلةً تلو الأخرى عند الوصول إليه. يُسبب أي عطل خطأً في الإدخال/الإخراج، وتتفاعل الخدمات والتطبيقات وفقًا لقدرتها على التحمل: إما الاستمرار بدون تلك البيانات أو التعطل تمامًا.
تصحيح الخطأ الأمامي (FEC)
منذ أندرويد 7.0، تم دمج FEC (Reed–Solomon) مع تقنيات التشابك لتقليل المساحة وزيادة إمكانية استعادة الكتل التالفة. يعمل هذا بالتزامن مع dm-verity: في حال فشل فحص، يمكن للنظام الفرعي محاولة تصحيحه قبل إعلانه غير قابل للاستعادة.
الأداء والتحسين
لتقليل التأثير: تمكين تسريع SHA-2 بواسطة NEON على ARMv7 وامتدادات SHA-2 على ARMv8 من النواة. اضبط معلمات القراءة المسبقة وprefetch_cluster لجهازك؛ عادةً ما يُضيف التحقق لكل كتلة القليل من تكلفة الإدخال/الإخراج، ولكن هذه الإعدادات تُحدث فرقًا.
البدء في استخدام Linux (systemd، veritysetup) وAndroid
على نظام Linux الحديث مع systemd، يسمح dm-verity بجذر للقراءة فقط تم التحقق منه باستخدام veritysetup (جزء من cryptsetup)، وsystemd-veritysetup.generator، وsystemd-veritysetup@.service. يُنصح بتضمين التمهيد الآمن وUKI مُوقّع (صورة نواة موحدة)، مع أنهما ليسا إلزاميين تمامًا.
التحضير والتقسيم الموصى به
جزء من نظام وظيفي ومعدل. حجز حجم لشجرة التجزئة (عادةً ما يكون ٨-١٠٪ من حجم الجذر كافيًا) وفكّر في فصل /home و/var عند الحاجة إلى الكتابة. يتضمن المخطط النموذجي: ESP (لأداة تحميل التشغيل)، وXBOOTLDR (لأجهزة UKI)، والجذر (مع أو بدون تشفير)، وقسم VERITY، واختياريًا /home و/var.
كجذر، EROFS هو بديل مثير للاهتمام للغاية لنظام ext4 أو squashfs:إنه للقراءة فقط من حيث التصميم، مع أداء جيد جدًا على الفلاش/SSD، وضغط lz4 افتراضيًا، ويُستخدم على نطاق واسع على هواتف Android مع dm-verity.
الملفات التي يجب أن تكون قابلة للكتابة
مع root ro، تتوقع بعض البرامج الكتابة إلى /إلخ أو أثناء التهيئةيمكنك نقله إلى /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
في Arch، إنه مناسب نقل قاعدة بيانات Pacman إلى /usr/lib/pacman بحيث يعكس نظام الملفات الجذر دائمًا الحزم المُثبّتة. بعد ذلك، أعد توجيه ذاكرة التخزين المؤقت إلى /var/lib/pacman واربطها. لتغيير قائمة المرايا دون المساس بالجذر، انقلها إلى /var/etc واربطها على أي حال.
مع NetworkManager، نقل اتصالات النظام إلى /var/etc/NetworkManager ورابط من /etc/NetworkManager/system-connections. هذا يُبقي الجذر ثابتًا، والتكوين حيًا حيث يجب أن يكون قابلًا للكتابة.
بناء الصدق والاختبار
من كائن حي ومع كل شيء مثالي ومركب في ro، قم بإنشاء الشجرة وجذورها مع تنسيق إعداد الحقيقةعند تشغيله، يطبع سطر تجزئة الجذر، والذي يمكنك حفظه في ملف roothash.txt. شغّله للاختبار باستخدام veritysetup، ثم افتح root-device (الجهاز الجذر) و/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 (منع الأصداف غير المصرح بها في حالة فشل التمهيد)، و الإغلاق = السرية لحماية ذاكرة النواة من الوصول.
أقسام إضافية مع التنوع
ليس فقط الجذر: يمكنك تعريف تعيينات أخرى في /etc/veritytab وسيقوم systemd-veritysetup@.service بتجميعها عند بدء التشغيل. تذكر: من الأسهل تثبيت قسم غير جذر (RW)، ويمكن للمستخدم الجذر تعطيل Verity على هذه الأقسام، لذا تكون قيمة الأمان هناك أقل.
الأمان: التمهيد الآمن، وUKI، والوحدات النمطية الموقعة
dm-verity ليس بمثابة رصاصة فضية. قم بتوقيع UKI وتمكين التمهيد الآمن باستخدام مفاتيحك الخاصة لمنع أي شخص من تجاوز kernel/initramfs/cmdline (الذي يتضمن تجزئة الجذر). تساعد أدوات مثل sbupdate-git أو sbctl في الحفاظ على الصور مُوقّعة وسلسلة التمهيد سليمة.
إذا قمت بتمكين قفل النواة أو التحقق من توقيع الوحدة النمطية، يجب توقيع وحدات DKMS أو وحدات خارج الشجرة أو لن يتم تحميلها. فكّر في استخدام نواة مخصصة مع دعم التوقيع لخط الأنابيب الخاص بك (انظر وحدات النواة الموقعة).
التشفير وTPM والقياس
dm-verity يحمي النزاهة، عدم السريةيمكنك ترك الجذر بدون تشفير إذا لم يكن يحتوي على أي أسرار وكانت سلسلة التمهيد محمية. إذا كنت تستخدم ملفات مفتاح الجذر لفتح مجلدات أخرى، فمن المستحسن تشفيرها.
مع 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 أو سطر الأوامر الخاص به.
التحديثات ونماذج النشر
جذر للقراءة فقط تم التحقق منه لا يتم تحديثه باستخدام مدير الحزم بالطريقة التقليدية. والمثالي هو بناء صور جديدة باستخدام أدوات مثل مشروع يوكتو ونشرها. يحتوي systemd على systemd-sysupdate وsystemd-repart لتنزيل الصور القوية وتحديثها.
استراتيجية أخرى مخطط أ/باحتفظ بجذرين ووثيقتي أصالة. انسخ الجذر النشط إلى الجذر غير النشط، ثم طبّق التغييرات، وأعد الأصالة. عد إلى التشغيل التالي. إذا كنت تستخدم UKI، فتذكر تحديث تجزئة الجذر في سطر الأوامر أو إعادة بناء UKI المُوقّع.
للاستمرار الاختياري، استخدم OverlayFS على الجذر الذي تم التحقق منه مع upper في tmpfs أو القرص. يمكنك أيضًا تمرير systemd.volatile=overlay للاستمرار المؤقت. يُسهّل Flatpak تثبيت التطبيقات في /var و/home دون الحاجة إلى لمس /.
توجد حزم آلية (على سبيل المثال verity-squash-root في AUR) تقوم ببناء جذر squashfs و قم بتوقيع roothash باستخدام kernel و initramfsيتيح لك الاختيار بين الوضع الدائم أو المؤقت، مع الاحتفاظ بأحدث نظام ملفات جذري كنسخة احتياطية. ملاحظة: إضافة وضع الاستمرارية إلى جذر مُتحقق له استخدامات محدودة؛ جرّب الاحتفاظ ببيانات التطبيق على أقسام منفصلة.
Android: النظام كجذر، وAVB، وتراكبات البائعين
منذ أندرويد 10، يتوقف RootFS عن التشغيل على قرص RAM ويتكامل مع system.img. (النظام كجذر). تستخدم الأجهزة التي تعمل بنظام Android 10 هذا النظام دائمًا، وتتطلب قرص ذاكرة وصول عشوائي (RAM) لملف dm-linear. تم ضبط BOARD_BUILD_SYSTEM_ROOT_IMAGE على "خطأ" في هذا الإصدار للتمييز بين استخدام قرص ذاكرة وصول عشوائي (RAM) وتفعيل ملف system.img مباشرةً.
يتضمن Android 10 الأقسام الديناميكية ومرحلة التهيئة الأولى الذي يُفعّل قسم النظام المنطقي؛ لم تعد النواة تُثبّته مباشرةً. تتطلب وكالات السفر عبر الهواء (OTA) المخصصة للنظام فقط تصميمًا يُمكّن النظام من العمل كجذر، وهو أمر إلزامي على أجهزة أندرويد 10.
في لا A/B، إبقاء الاسترداد منفصلاً عن التمهيدعلى عكس A/B، لا يوجد نسخة احتياطية boot_a/boot_b، لذا فإن إزالة الاسترداد في وضع غير A/B قد يتركك بدون وضع الاسترداد إذا فشل تحديث التمهيد.
يقوم kernel بتثبيت system.img إلى /converity عبر مسارين: vboot 1.0 (تصحيحات للنواة لتحليل بيانات التعريف الخاصة بنظام Android في /system واستخلاص معلمات dm-verity؛ يتضمن سطر الأوامر root=/dev/dm-0 وskip_initramfs وinit=/init مع dm=…) أو vboot 2.0/AVB، حيث يقوم برنامج التشغيل بدمج libavb، ويقرأ موصوف Hashtree (في vbmeta أو النظام)، وينشئ المعلمات ويمررها إلى kernel في cmdline، مع دعم FEC والأعلام مثل restart_on_corruption.
مع النظام كجذر، لا تستخدم BOARD_ROOT_EXTRA_FOLDERS للمجلدات الجذرية الخاصة بالجهاز: ستختفي هذه المجلدات عند تثبيت GSI. حدّد مواقع تحميل محددة ضمن /mnt/vendor/ ، والتي يقوم fs_mgr بإنشائها تلقائيًا، والإشارة إليها في fstab لشجرة الجهاز.
يسمح Android بـ تراكب البائع من /product/vendor_overlay/: سيقوم init بتركيب الدلائل الفرعية في /vendor التي تلبي متطلبات سياق SELinux ووجود /vendor/ . يتطلب CONFIG_OVERLAY_FS=yy، في النوى الأقدم، التصحيح override_creds=off.
التنفيذ النموذجي: يقوم بتثبيت الملفات المترجمة مسبقًا في الجهاز/ / /تراكب البائع/أضفها إلى PRODUCT_COPY_FILES باستخدام الأمر find-copy-subdir-files في $(TARGET_COPY_OUT_PRODUCT)/vendor_overlay، وحدد السياقات في file_contexts لـ etc والتطبيق (مثل vendor_configs_file وvendor_app_file)، واسمح بالتثبيت على هذه السياقات في init.te. اختبرها باستخدام atest vfs_mgr_vendor_overlay_test في userdebug.
استكشاف الأخطاء وإصلاحها: رسالة تلف dm-verity على Android
في الأجهزة التي تحتوي على فتحات A/B، قم بتغيير الفتحات أو وميض vbmeta/boot دون اتساق roothash قد يؤدي هذا إلى ظهور التحذير: تلف dm-verity، جهازك غير موثوق. أوامر مثل fastboot flash –disable-verity –disable-verification vbmeta vbmeta.img تُعطّل عملية التحقق، لكنها تترك النظام دون أي ضمانات للسلامة.
بعض أجهزة تحميل التشغيل تدعم fastboot oem disable_dm_verity وعكسه، enable_dm_verity. يعمل على بعض الطُرز، ولكن لا يعمل على أخرى؛ وقد يتطلب نواة/ماجيسك مع علامات مُعدّلة. استخدمه على مسؤوليتك الخاصة: الإجراء الأمثل هو محاذاة التمهيد وvbmeta والنظامقم بتوقيع الشجرة أو إعادة إنشائها وتأكد من أن تجزئة الجذر المتوقعة تتطابق مع تلك التي تم تكوينها.
إذا تمكنت بعد التحذير من الاستمرار في الضغط على زر الطاقة، فسيبدأ النظام، ولكن لم يعد لديك سلسلة ثقة سليمةلإزالة الرسالة دون التضحية بالأمان، قم باستعادة الصور الموقعة الأصلية أو إعادة بناء/التحقق من vbmeta باستخدام شجرة التجزئة الصحيحة، بدلاً من تعطيل التحقق.
منصات i.MX وOpenWrt
على i.MX6 (على سبيل المثال sabresd)، قم بتكوين النواة مع دعم DM_VERITY وFECأنشئ الشجرة باستخدام veritysetup، وخزّن تجزئة الجذر بأمان، ومرّر المعلمات المناسبة في سطر cmd، أو تكامل عبر initramfs مع systemd-veritysetup. إذا لم تستخدم dm-crypt، فلن تحتاج إلى CAAM لـ verity؛ فالتركيز منصبّ على السلامة.
في OpenWrt وفي أنظمة Linux المضمنة مع OpenEmbedded, هناك جهود لدمج dm-verity و SELinux (تمت مراجعة وظائف Bootlin بهدف تضمين الدعم). إنه أمر طبيعي: تستفيد أجهزة التوجيه ومعدات الشبكة من جذر ثابت ومُتحقق منه ومُعزز بـ MAC.
إنشاء شجرة يدوية وبيانات وصفية (عرض تفصيلي)
يمكن لـ cryptsetup إنشاء الشجرة لك، ولكن إذا كنت تفضل فهم التنسيق، فإن تعريف سطر الجدول المضغوط يتضمن: اسم التعيين، وجهاز البيانات، وحجم كتلة البيانات والتجزئة، وحجم الصورة في الكتل، وموضع بداية التجزئة (صورة الكتلة + 8 إذا كانت متسلسلة)، وتجزئة الجذر، والملح. بعد إنشاء الطبقات المتسلسلة (من الأعلى إلى الأسفل، باستثناء الطبقة 0)، اكتب الشجرة على القرص.
لتعبئة كل شيء، إنشاء جدول dm-verity، وتوقيعه (نموذجي في RSA-2048) وتجميع التوقيع + الجدول في البيانات الوصفية مع رأس مُحدَّد الإصدار ورقم سري. ثم يُدمج صورة النظام وبيانات Verity الوصفية وشجرة التجزئة. في fstab، يُحدِّد fs_mgr كـ Verify، ويضع المفتاح العام في /boot/verity_key للتحقق من صحة التوقيع.
تحسين مع تسريع SHA-2 لوحدة المعالجة المركزية الخاصة بك على أجهزة ARM، تُخفِّض امتدادات NEON SHA-2 (ARMv7) وSHA-2 (ARMv8) تكلفة التحقق بشكل ملحوظ.
في أي نشر، تذكر أن يجب حماية قيمة التجزئة الجذريةسواءً تم تجميعها في ملف UKI مُوَقَّع، أو في قسم تمهيد مُوَقَّع، أو تم التحقق من صحتها بواسطة مُحمِّل الإقلاع باستخدام AVB. كل شيء بعد هذه النقطة يرث هذه الثقة.
مع كل ما سبق في مكانه، يصبح dm-verity أساس متين للأنظمة الثابتة والمتحركة والمضمنة، ودعم التحديثات المعاملاتية، وتراكبات التكوين، ونموذج أمان حديث يقلل من سطح الهجوم ويمنع الثبات دون التضحية بالأداء.
