اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
التحقّق من التشغيل
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تتطلّب ميزة "التمهيد التحقق منه" التحقّق من صحة جميع الرموز البرمجية والبيانات القابلة للتنفيذ
التي تشكّل جزءًا من إصدار Android الذي يتم تشغيله قبل استخدامه. ويشمل ذلك
النواة (التي يتم تحميلها من القسم boot) وشجرة الجهاز (التي يتم تحميلها
من القسم dtbo) والقسم system
والقسم vendor وما إلى ذلك.
بالنسبة إلى الأقسام الصغيرة، مثل boot وdtbo، التي تتم قراءتها
مرة واحدة فقط، يتم عادةً التحقّق منها عن طريق تحميل المحتوى بالكامل في الذاكرة ثم حساب التجزئة. بعد ذلك، تتم مقارنة قيمة التجزئة المحسوبة ب
قيمة التجزئة المتوقّعة. إذا لم تتطابق القيمة، لن يتم تحميل نظام التشغيل Android.
لمزيد من التفاصيل، يُرجى الاطّلاع على مسار التشغيل.
بالنسبة إلى الأقسام الأكبر حجمًا التي لا تتسع في الذاكرة (مثل أنظمة الملفات)، قد تستخدم
شجرة تجزئة يكون فيها التحقّق عملية مستمرة تحدث أثناء تحميل البيانات
إلى الذاكرة. في هذه الحالة، يتم احتساب تجزئة الجذر لشجرة التجزئة
أثناء وقت التشغيل ويتم التحقّق منها مقابل قيمة تجزئة الجذر المتوقّعة.
يتضمّن نظام التشغيل Android برنامج تشغيل dm-verity للتحقّق من الأقسام الأكبر حجمًا. إذا لم تتطابق قيمة التجزئة المُحتسَبة للملف الأساسي في وقت معيّن مع قيمة تجزئة الملف الأساسي المتوقّعة، لن يتم استخدام البيانات
ويدخل Android في حالة خطأ. لمزيد من التفاصيل، يُرجى الاطّلاع على تلف ملف dm-verity.
يتم عادةً تخزين التجزئات المتوقّعة في نهاية أو بداية
كل قسم تم إثبات ملكيته، أو في قسم مخصّص، أو كليهما. من المهمّ الإشارة إلى أنّه يتم توقيع هذه
التجزئات (سواء مباشرةً أو غير مباشرة) من خلال جذر الثقة. على سبيل المثال، يتيح تنفيذ AVB كلا الطريقتَين، راجِع
التشغيل المُتحقّق منه في Android للاطّلاع على التفاصيل.
الحماية من الرجوع إلى الحالة السابقة
حتى في حال إجراء عملية تحديث آمنة تمامًا، من الممكن أن تؤدي ميزة استغلال ملف kernel في نظام التشغيل Android غير الثابتة إلى تثبيت إصدار قديم من Android يتضمن ثغرة أمنية بشكل يدوي، ثم إعادة تشغيل الجهاز للانتقال إلى الإصدار الذي يتضمّن ثغرة أمنية، ثم استخدام هذا الإصدار من Android لتثبيت ميزة استغلال ثابتة. ومن هنا، يصبح المهاجم مالكًا للجهاز بشكل دائم ويحقّ له تنفيذ أي إجراء، بما في ذلك إيقاف التحديثات.
تُعرف الحماية من هذا النوع من الهجمات باسم الحماية من الترجيع. يتم عادةً تنفيذ ميزة "الحماية من الرجوع إلى إصدار سابق" باستخدام
مساحة تخزين مقاومة للتلاعب لتسجيل أحدث إصدار من Android و
رفض تشغيل Android إذا كان إصداره أقل من الإصدار المسجَّل. يتم عادةً تتبُّع الإصدارات
على أساس كل قسم.
لمزيد من التفاصيل حول كيفية تعامل بروتوكول AVB مع وسائل الحماية من التراجع، يُرجى الاطّلاع على ملف README الخاص ببروتوكول AVB.
التعامل مع أخطاء التحقّق
يمكن أن يتعذّر إثبات صحة المحتوى إما في وقت التشغيل (مثلاً، إذا لم تتطابق التجزئة المحسوبة في القسم
boot مع التجزئة المتوقّعة) أو في وقت التشغيل
(مثلاً، إذا واجه dm-verity خطأ في إثبات صحة المحتوى في القسم
system). إذا تعذّر إثبات الملكية في وقت التشغيل، لن تتمكّن من تشغيل الجهاز، ويجب على المستخدم النهائي اتّباع الخطوات اللازمة لاسترداد الجهاز.
إذا تعذّر إثبات الملكية أثناء التشغيل، يصبح الإجراء أكثر تعقيدًا. إذا كان
الجهاز يستخدم dm-verity، يجب ضبطه في وضع restart. في وضع
restart، إذا حدث خطأ في عملية التحقّق، تتم إعادة تشغيل الجهاز
على الفور مع ضبط علامة معيّنة للإشارة إلى السبب. من المفترض أن يلاحظ مثبّت التمهيد
هذه العلامة ويبدّل dm-verity لاستخدام وضع خطأ I/O
(eio) ويبقى في هذا الوضع إلى أن يتم تثبيت تحديث جديد.
عند التشغيل في وضع eio، يعرض الجهاز شاشة خطأ
تُعلم المستخدم بأنّه تم رصد تلف في البيانات وأنّ الجهاز قد لا يعمل
بشكل صحيح. تظهر الشاشة إلى أن يغلقها المستخدم. في وضع
eio، لن يعيد برنامج تشغيل dm-verity تشغيل الجهاز في حال حدث خطأ في
التحقّق، بل سيظهر خطأ EIO بدلاً من ذلك وعلى
التطبيق التعامل مع الخطأ.
والهدف من ذلك هو إما تشغيل أداة تحديث النظام (كي يتم تثبيت نظام تشغيل جديد بدون أخطاء
فساد) أو أن يتمكّن المستخدم من نقل أكبر قدر ممكن من بياناته
خارج الجهاز. بعد تثبيت نظام التشغيل الجديد، يرصد مشغّل الإقلاع
نظام التشغيل المثبَّت حديثًا ويعود إلى وضع restart.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Verify Boot\n\nVerified Boot requires cryptographically verifying all executable code and data\nthat is part of the Android version being booted before it is used. This includes\nthe kernel (loaded from the `boot` partition), the device tree (loaded\nfrom the `dtbo` partition), `system` partition,\n`vendor` partition, and so on.\n\n\nSmall partitions, such as `boot` and `dtbo`, that are read\nonly once are typically verified by loading the entire contents into memory and\nthen calculating its hash. This calculated hash value is then compared to the\n*expected hash value* . If the value doesn't match, Android won't load.\nFor more details, see [Boot Flow](/docs/security/features/verifiedboot/boot-flow).\n\n\nLarger partitions that won't fit into memory (such as, file systems) may use\na hash tree where verification is a continuous process happening as data is\nloaded into memory. In this case, the root hash of the hash tree is calculated\nduring run time and is checked against the *expected root hash value* .\nAndroid includes the [dm-verity\ndriver](/docs/security/features/verifiedboot/dm-verity) to verify larger partitions. If at some point the calculated root\nhash doesn't match the *expected root hash value* , the data isn't used\nand Android enters an error state. For more details, see\n[dm-verity\ncorruption](/docs/security/features/verifiedboot/boot-flow#dm-verity-corruption).\n\n\nThe *expected hashes* are typically stored at either the end or beginning\nof each verified partition, in a dedicated partition, or both. Crucially, these\nhashes are signed (either directly or indirectly) by the root of trust. As an\nexample, the AVB implementation supports both approaches, see\n[Android Verified Boot](/docs/security/features/verifiedboot/avb) for details.\n\nRollback protection\n-------------------\n\n\nEven with a completely secure update process, it's possible for a non-persistent\nAndroid kernel exploit to manually install an older, more vulnerable version of\nAndroid, reboot into the vulnerable version, and then use that Android version to\ninstall a persistent exploit. From there the attacker permanently owns the device\nand can do anything, including disabling updates.\n\n\nThe protection against this class of attacks is called *Rollback\nProtection*. Rollback protection is typically implemented by using\ntamper-evident storage to record the most recent version of the Android and\nrefusing to boot Android if it's lower than the recorded version. Versions\nare typically tracked on a per-partition basis.\n\n\nFor more details on how AVB handles rollback protections, see the AVB\n[README](https://android.googlesource.com/platform/external/avb/+/android16-release/README.md#Rollback-Protection).\n\nHandle verification errors\n--------------------------\n\n\nVerification can fail either at boot time (such as, if the calculated hash on\n`boot` partition doesn't match the expected hash) or at run time\n(such as, if dm-verity encounters a verification error on the\n`system` partition). If verification fails at boot time, the device\ncan't boot and the end user needs to go through steps to recover the device.\n\n\nIf verification fails at run-time the flow is a bit more complicated. If the\ndevice uses dm-verity, it should be configured in `restart` mode. In\n`restart` mode, if a verification error is encountered, the device is\nimmediately restarted with a specific flag set to indicate the reason. The boot\nloader should notice this flag and switch dm-verity over to use I/O Error\n(`eio`) mode and stay in this mode until a new update has been\ninstalled.\n\n\nWhen booting in `eio` mode, the device shows an error screen\ninforming the user that corruption has been detected and the device might not\nfunction correctly. The screen shows until the user dismisses it. In\n`eio` mode the dm-verity driver won't restart the device if a\nverification error is encountered, instead an EIO error is returned and the\napp needs to deal with the error.\n\n\nThe intent is that either the system updater will run (so a new OS without\ncorruption errors can be installed) or the user can get as much of their data\noff the device as possible. Once the new OS has been installed, the boot loader\nnotices the newly installed OS and switches back to `restart` mode."]]
