اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تعالج أجهزة الحوسبة الجوّالة كميات متزايدة من البيانات الشخصية العميقة الصلة بالخصوصية. وقد أدّى توفّر هذه البيانات الحسّاسة، بالإضافة إلى الربط المستمر
بالعالم الخارجي، إلى زيادة الاستثمارات من قبل
الجهات الفاعلة الضارّة المهتمة باستغلال الثغرات الأمنية لتحقيق أهدافها.
توفّر أنظمة التشغيل، بمساعدة وحدات إدارة الذاكرة (MMU) في الأجهزة،
عمليات تجريدية تعزل العمليات غير ذات الصلة ببعضها. لا يُسمح إلا
للمكونات التي تشكّل جزءًا من Trusted Computing Base (قاعدة الحوسبة الموثوق بها)
برمجة وحدات إدارة الذاكرة هذه مباشرةً.
وقد كان هذا النموذج هو الأساس الذي تم على أساسه تنفيذ الخصوصية والأمان
منذ طرح أنظمة التشغيل المشابهة لنظام التشغيل Unix. ومع ذلك، أصبح هذا المتطلّب مشكلةً لأنّ مساحة التخزين المؤقتة للعمليات (TCB) الحالية كبيرة جدًا: فهي تتضمّن
معظم برامج تشغيل الأجهزة واللوحة، وجداول التشغيل المعقدة، وأنظمة الملفات، ومجموعة بروتوكولات الشبكة
والذاكرة المؤقتة، وبرامج التحليل والتحميل القابلة للتنفيذ، ووحدات الجلسة. أصبح من الصعوبة بمكانٍ
ضمان أمان كل جزء من هذا النظام المعقّد.
يتضمّن نواة Linux أكثر من 20 مليون سطر من الرموز البرمجية، ومعدل التغييرات والإعادة الرائعة. ويشكّل هذا النمو مساعدة كبيرة لنظام Android ومنظومة Android المتكاملة. ومع ذلك، فإنّ حجم قاعدة بيانات الاعتمادات الثقيلة يجعل من الصعب التأكّد من عدم توفّر
ثغرات أمنية قابلة للاستغلال.
طوّر مورّدو الأجهزة حلولاً، مثل TrustZone من Arm، التي تسمح
للمعالجات بالعمل في الوضع الآمن وتصنيف معاملات الذاكرة على أنّها "آمنة" أو
"غير آمنة". في هذه الأنظمة، يتم تخزين البيانات الحسّاسة في "العالم الآمن"، وهو المكان الوحيد الذي يمكنه الوصول إليها مباشرةً، ويوفّر "العالم الآمن" خدمات "للعالم غير الآمن" عند الطلب.
يتمثل القيد الرئيسي لهذا النوع من الحلول في أنّ النطاقات فائقة الصعوبة: آمنة وغير آمنة فقط. مع زيادة حالات الاستخدام التي تتطلّب
عزل التطبيق عن نظام التشغيل، تزداد الأسطح المعرضة للهجوم
ومن المحتمل أن تؤدي الثغرات الأمنية إلى اختراق الجهاز بالكامل.
ومن القيود الأخرى للحلول الحالية أنّها مصمّمة لبيئة
ساكنة نسبيًا يتم فيها احتساب جميع موارد حالات الاستخدام وتحديدها
مسبقًا. هذه الحلول ليست جيدة بما يكفي للاستخدام الديناميكي،
أي الحالات التي يتم فيها تخصيص الموارد عند الطلب.
بالإضافة إلى ذلك، فإنّ واجهات برمجة التطبيقات المستخدَمة خارج نظام التشغيل Android متشتّتة وتقيّد قدرتنا على نشر حالات الاستخدام على مستوى Android،
بما في ذلك الأساسيات مثل Keymint وGatekeeper.
لحلّ هذه القيود وتمكين Android من توفير أساس قوي
لحالات الاستخدام من الجيل التالي، يقدّم الإصدار 13 من Android
تكنولوجيا المحاكاة الافتراضية الآمنة كإطار عمل المحاكاة الافتراضية في Android (AVF).
يتمثل الهدف الرئيسي من AVF في توفير بيئة تنفيذ آمنة وخاصة
لحالات الاستخدام من الجيل التالي.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ 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,["# Why AVF?\n\nMobile computing devices are handling increasingly larger amounts of personally\nsensitive data. The presence of such sensitive data, aided by the constant\nconnection to the outside world, has resulted in increased investments from\nmalicious actors interested in exploiting vulnerabilities to further their goals.\n\nOperating systems, with the help of hardware memory management units (MMUs),\nprovide abstractions that isolate unrelated processes from each other. Only\ncomponents that are part of the Trusted Computing Base (TCB) are allowed to\ndirectly program these MMUs.\n\nThis model has been the foundation of how privacy and security have been\nimplemented since the introduction of Unix-like operating systems. However, this\nrequirement has become problematic in that today's TCB is too large: it includes\nmost device and bus drivers, complex schedulers, file systems, network stack and\nprotocols, caches, executable parsers and loaders, and sockets. It has become\nvery difficult to ensure every corner of this complicated system is safe.\n\nThe Linux kernel has over 20 million lines of code and the rate of changes and\nrewrites is astonishing. This growth is an immense help to Android and our\necosystem. However its large TCB makes it difficult to ensure the absence of\nexploitable vulnerabilities.\n\nHardware vendors have developed solutions, such as Arm's TrustZone, which allow\nprocessors to run in Secure mode and tag memory transactions as \"secure\" or\n\"nonsecure.\" In such systems, sensitive data is stored in and only directly\navailable to the secure world, which provides services to the nonsecure world\non demand.\n\nThe main limitation of these kind of solutions is that the domains are too\ncoarse-grained: only secure and nonsecure. As more use cases that require\nisolation from the operating system are introduced, the attack surface increases\nand vulnerabilities are likely to lead to compromise of the entire device.\n\nAnother limitation of today's solutions is that they're designed for a\nrelatively static world in which all use case resources are accounted for and\nallocated ahead of time. These solutions aren't good enough for dynamic use\ncases in which resources are allocated on demand.\n\nIn addition, the APIs used outside of the Android operating system are\nfragmented and restrict our ability to deploy use cases at the Android scale,\nincluding fundamentals like Keymint and Gatekeeper.\n\nTo address these limitations and enable Android to provide a robust foundation\nfor next generation use cases, Android 13 introduces\nsecure virtualization as the Android Virtualization Framework (AVF).\n\nThe main goal of AVF is to provide a secure and private execution environment\nfor next-generation use cases.\n| **Note:** AVF doesn't fully replace TrustZone. Today, Android SoCs can't function without TrustZone as key devices assume secure access only."]]
