از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
دستگاه‌های محاسباتی سیار با حجم فزاینده‌ای از داده‌های حساس شخصی مدیریت می‌کنند. وجود چنین داده‌های حساسی، به کمک ارتباط دائمی با دنیای خارج، منجر به افزایش سرمایه‌گذاری از سوی بازیگران مخربی شده است که علاقه‌مند به بهره‌برداری از آسیب‌پذیری‌ها برای پیشبرد اهداف خود هستند.
سیستم عامل ها با کمک واحدهای مدیریت حافظه سخت افزاری (MMU) انتزاعیاتی را ارائه می کنند که فرآیندهای نامرتبط را از یکدیگر جدا می کند. فقط مؤلفه هایی که بخشی از پایگاه محاسباتی معتمد (TCB) هستند مجاز به برنامه ریزی مستقیم این MMUها هستند.
این مدل پایه و اساس نحوه پیاده سازی حریم خصوصی و امنیت از زمان معرفی سیستم عامل های شبه یونیکس بوده است. با این حال، این نیاز از این جهت مشکل ساز شده است که TCB امروزی بسیار بزرگ است: شامل اکثر درایورهای دستگاه و اتوبوس، زمانبندی پیچیده، سیستم های فایل، پشته شبکه و پروتکل ها، حافظه پنهان، تجزیه کننده ها و بارگذارهای اجرایی و سوکت ها می شود. اطمینان از ایمن بودن هر گوشه از این سیستم پیچیده بسیار دشوار شده است.
هسته لینوکس بیش از 20 میلیون خط کد دارد و سرعت تغییرات و بازنویسی ها شگفت انگیز است. این رشد کمک بزرگی به اندروید و اکوسیستم ما است. با این حال TCB بزرگ آن اطمینان از عدم وجود آسیب پذیری های قابل بهره برداری را دشوار می کند.
فروشندگان سخت افزار راه حل هایی مانند Arm's TrustZone ایجاد کرده اند که به پردازنده ها اجازه می دهد در حالت امن اجرا شوند و تراکنش های حافظه را به عنوان "امن" یا "غیر امن" برچسب گذاری کنند. در چنین سیستم‌هایی، داده‌های حساس در دنیای امن ذخیره می‌شوند و فقط مستقیماً در دسترس آن هستند، که خدماتی را در صورت تقاضا به دنیای غیرایمن ارائه می‌کند.
محدودیت اصلی این نوع راه حل ها این است که دامنه ها بیش از حد درشت هستند: فقط ایمن و غیر ایمن. با معرفی موارد استفاده بیشتر که نیاز به جداسازی از سیستم عامل دارند، سطح حمله افزایش می‌یابد و آسیب‌پذیری‌ها احتمالاً منجر به به خطر انداختن کل دستگاه می‌شوند.
یکی دیگر از محدودیت‌های راه‌حل‌های امروزی این است که آنها برای دنیای نسبتاً ثابتی طراحی شده‌اند که در آن همه منابع مورد استفاده زودتر از موعد محاسبه و تخصیص داده می‌شوند. این راه حل ها برای موارد استفاده پویا که در آن منابع بر اساس تقاضا تخصیص داده می شود، به اندازه کافی خوب نیستند.
علاوه بر این، APIهای مورد استفاده خارج از سیستم عامل اندروید تکه تکه هستند و توانایی ما را برای استقرار موارد استفاده در مقیاس Android، از جمله موارد اساسی مانند Keymint و Gatekeeper، محدود می کنند.
برای رفع این محدودیت‌ها و فعال کردن اندروید برای ارائه پایه‌ای قوی برای موارد استفاده نسل بعدی، اندروید 13 مجازی‌سازی امن را به عنوان چارچوب مجازی‌سازی اندروید (AVF) معرفی می‌کند.
هدف اصلی AVF ارائه یک محیط اجرای امن و خصوصی برای موارد استفاده نسل بعدی است.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]
