2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
사용 사례
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이 문서에는 AVF의 일반적인 사용 사례가 포함되어 있습니다.
격리된 컴파일
보호된 VM은 소프트웨어 보안 인클레이브로서 보안에 민감한 코드를 컴파일할 수 있는 안전한 환경을 제공합니다. 이 환경을 사용하면 bootclasspath
및 시스템 서버 JAR의 컴파일(APEX 업데이트에 의해 트리거됨)을 초기 부팅에서 재부팅 전으로 이동할 수 있으며 APEX 업데이트 후 부팅 시간이 크게 줄어듭니다.
구현은 com.android.compos
APEX에 있습니다. 이 구성요소는 선택사항이며 makefile을 사용하여 포함할 수 있습니다.
그림 1. 메인라인 업데이트에서 JAR 컴파일
보안 목표는 확인된 입력을 실제로 컴파일하고 출력을 입력과 격리하여 생성하는 것입니다. 신뢰할 수 없는 클라이언트로서 Android는 (Android가 부팅 시간 컴파일로 대체되는 경우) 실패를 일으키지 않고 컴파일 출력을 변경할 수 있는 방법이 없습니다.
VM의 컴파일 서비스는 전체 컴파일 중에 오류가 없는 경우에만 서명을 생성합니다. Android는 서명 확인을 위해 VM에서 공개 키를 가져올 수 있습니다.
VM의 키는 다른 VM 매개변수(예: 디버깅 가능 여부)와 함께 VM의 DICE 프로필에서 생성되며 이 프로필은 VM에 마운트된 APEX 및 APK에서 정의합니다.
공개 키가 예기치 않은 VM에서 비롯되지 않았는지 확인하기 위해 Android는 VM을 부팅하여 키가 올바른지 확인합니다. 각 APEX 업데이트 후 초기 부팅 시 VM이 부팅됩니다.
보호된 VM의 자체 검사 부팅을 사용하면 컴파일 서비스가 확인된 코드만 실행합니다. 따라서 코드는 특정 조건을 충족하는 입력만 허용하도록 결정할 수 있습니다. 예를 들어 허용 목록에 이름과 fs-verity
다이제스트가 정의된 경우에만 입력 파일을 허용할 수 있습니다.
VM에서 노출된 모든 API는 공격에 노출되는 영역에 있습니다. 모든 입력 파일과 매개변수는 신뢰할 수 없는 클라이언트에서 비롯된 것으로 간주되며 처리 전에 확인 및 검증되어야 합니다.
입력/출력 파일 무결성은 파일이 신뢰할 수 없는 파일 서버로서의 Android에 저장된 상태에서 다음과 같이 VM이 확인합니다.
fs-verity
알고리즘을 사용하여 파일을 사용하기 전에 입력 파일의 콘텐츠를 확인해야 합니다. 입력 파일을 VM에서 사용할 수 있으려면 VM의 DICE 프로필에 사용되는 컨테이너(APK)에 루트 해시를 제공해야 합니다. 신뢰할 수 있는 루트 해시를 사용하면 공격자가 감지되지 않은 상태에서 입력을 조작할 수 없습니다.
- 출력 파일의 무결성은 VM에서 유지되어야 합니다. 출력 파일이 Android에 저장되더라도 생성 중에는 무결성이 동일한
fs-verity
트리 형식으로 유지되지만 동적으로 업데이트될 수 있습니다. 최종 출력 파일은 VM에서 격리된 루트 해시로 식별할 수 있습니다. VM의 서비스는 서명으로 출력 파일을 보호합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2024-08-07(UTC)
[[["이해하기 쉬움","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"]],["최종 업데이트: 2024-08-07(UTC)"],[],[],null,["# Use cases\n\nThis page contains common use cases for AVF.\n\nIsolated compilation\n--------------------\n\nAs a software-secure enclave, a protected virtual machine (VM) provides\na safe environment to compile security-sensitive code.\nThis environment allows moving the compilation\nof `bootclasspath` and system server JARs (triggered by an APEX update) from\nearly boot to before reboot, and significantly reduces the post APEX\nupdate boot time.\n\nThe implementation is in the [`com.android.compos`](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Virtualization/build/compos/Android.bp) APEX. This\ncomponent is optional and can be included using a [makefile](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Virtualization/build/apex/product_packages.mk).\n\n\n**Figure 1.** Compiling JARs on Mainline updates. Compiling JARs on Mainline updates\n\n\u003cbr /\u003e\n\nThe security goal is to truthfully compile verified input and produce the output\nin isolation; Android as an untrusted client can't alter the compilation\noutput in any way other than causing it to fail (when Android falls back to boot\ntime compilation).\n\nThe compilation service in the VM generates a signature only if there's no\nerror during the entire compilation. Android can retrieve the public key from\nthe VM for signature verification.\n\nThe VM's key is generated from the VM's DICE profile, defined by the APEXes\nand APKs mounted to the VM, in addition to other VM parameters, such as\ndebuggability.\n\nTo determine if the public key isn't from an unexpected VM, Android boots\nthe VM to determine if the key is correct. The VM is booted at early boot\nafter each APEX update.\n\nWith Protected VM's Verified Boot, the compilation service runs only verified\ncode. As a result the code can therefore determine to accept only inputs that\nsatisfy certain conditions, for example, accept an input file only where its\nname and the `fs-verity` digest are defined in an allowlist.\n\nAny exposed APIs from the VM are attack surfaces. All input files and\nparameters are assumed to be from an untrusted client, and must be verified and\nvetted before processing.\n\nInput and output file integrity is verified by the VM, with the files stored on\nAndroid as an untrusted file server, as follows:\n\n- The content of an input file must be verified before use using the `fs-verity` algorithm. For an input file to become available in the VM, its root hash must be provided in a container (APK) that contributes to the VM's DICE profile. With the trusted root hash, an attacker can't tamper with the input without being detected.\n- The integrity of the output file must be maintained in the VM. Even if an output file is stored on Android, during the generation, the integrity is maintained with the same `fs-verity` tree format but can be dynamically updated. The final output file can be identified with the root hash, which is isolated in the VM. The service in the VM protects the output files by signature.\n\nLinux development environment\n-----------------------------\n\nAndroid has traditionally been the only major operating system\nthat doesn't let users develop apps on the platform itself.\nWith the introduction of the Linux development environment,\nwe aim to provide a Linux-based development environment to Android\nusers who are developers. In the future, we plan to expand the effort\nto make it possible for our partners to implement innovative VM\nuse cases like running graphical user interface apps and even games.\n\nThe Linux development environment is available on select devices and runs\nin a non protected virtual machine.\n\n\n**Figure 2.** Linux development environment use case.\n\n\u003cbr /\u003e\n\nThe high-level flow is as follows:\n\n1. To use the Linux development environment, [enable developer options](https://developer.android.com/about/versions/15/release-notes#linux-development-environment).\n2. After you enable developer options, the Terminal app appears on your home launcher.\n3. Launch the Terminal app from your home launcher.\n4. If required, the Terminal app downloads the OS image from Play.\n5. The Terminal app uses the Android Virtualization Framework (AVF) to create a virtual machine (VM).\n6. AVF then runs the VM with the OS image.\n7. The virtual machine boots the OS from the image.\n8. After the VM boots, the WebView in the Terminal app connects to a web service in the virtual machine. This service provides terminal access over HTTP.\n9. You interact with the terminal by entering commands and viewing the output in the app.\n\nThe high-level components of the Linux VM are as follows:\n\n- **Terminal app:** An Android application providing a terminal interface. It uses a WebView to connect to a web service running in the VM for interaction. This app is disabled by default. Activate it in Developer Settings.\n- **Android Virtualization Framework (AVF):** Android's existing subsystem for VM creation and management. It requires minimal modification to support custom OS images for this feature.\n- **virtual machine:** A VM that AVF generates. It hosts the terminal service, and AVF creates it specifically for the Terminal app's functionality.\n- **OS image:** A slightly modified Debian-based OS image from upstream Debian. The Terminal app downloads this image from an external Google server. It serves as the foundation for the VM's operation.\n- **Guest Agent:** New software in the VM. It reports the OS's state to AVF and provides control of the virtual machine.\n- **ttyd**: Open-source software running in the VM that implements terminal emulation over HTTP. The Terminal app's WebView connects to it.\n- **Tethering Manager:** An existing Android subsystem. It provides network access to the virtual machine by tethering the VM to the Android-powered device.\n\nContent Safety On-Device\n------------------------\n\nContent Safety On-device is a privacy-preserving content safety solution created\nby the Content Safety On-device Team. It performs content safety classification\nfor various Google products on 1P/3P devices, and protects 1B+ users from\nabusive content, without requiring user data being sent back to Google servers.\nIt is designed to adhere to [Private Compute Core (PCC)](https://security.googleblog.com/2022/12/trust-in-transparency-private-compute.html)\nprinciples to verify transparent and privacy-preserving communication between\nthe client, the virtual machine (VM), and preventing any exfiltration of user\ndata. It can be used for things such as enabling abuse detection on devices,\nsuch as [Play Protect live threat detection](https://developers.google.com/android/play-protect).\n\nIn this use case, the system utilizes protected virtual machines to run its\nmodel classification for Play Protect live threat detection which then\nsignificantly enhances the security of its models and protections. This prevents\nreverse engineering and manipulation by attackers, even on rooted devices, by\nverifying only approved code runs and its operations are hidden from external\nprocesses.\n| **Note:** This specific use case is enabled on select devices supporting Play Protect live threat detection and AVF. Play Protect live threat detection will utilize AVF when available.\n\nThe high level flows are as follows:\n\n1. Live threat detection pings Private Compute Services to start the VM. Private Compute Services is a privacy-centric intermediary between the PCC and the cloud server\n2. Private Compute Services starts the VM and gets its public key from the VM\n3. Private Compute Services hands over VM ownership to Play Protect live threat detection\n4. Private Compute Services sends attestation and public key to the server\n5. Server verifies attestation and encrypt protections with VM public key\n6. Server then sends the encrypted protections back to the device\n7. Then, the on-device live threat detection can utilize encrypted protection within the VM. The VM is the only entity with the private key which can decrypt the protections\n\nThe high level component are as follows:\n\n- Server: Encrypt and deliver encrypted protections to the VM\n- Private Compute Services: Used to start the VM and mediate the communication to the VM and show transparency that no user data is going through Astrea to server\n- Play Protect live threat detection:\n - Contains and uses model classifiers provided by Content Safety on-device\n - Accepts ownership of the VM and holds it for classification use\n - Starts and stops the VM as needed.\n\nOEMs\n----\n\nAn OEM can use the AVF for custom use cases.\nFor example, OPPO uses AVF to enable its\n[AI private computing space](https://mp.weixin.qq.com/s/c2x1AdbAJJ0LNQt7PmHahA). This space's first application\nprovides an on-device risk control solution for app clients, running in a\nvirtual machine. The system counters threats from illicit activities,\noffering protection against various hazards."]]