Use cases

Stay organized with collections Save and categorize content based on your preferences.

This document contains common use cases for AVF.

Isolated compilation

As a software-secure enclave, a protected VM provides a safe environment to compile security-sensitive code. This environment allows moving the compilation of bootclasspath and system server JARs (triggered by an APEX update) from early boot to before reboot, and significantly reduces the post APEX update boot time.

The implementation is in the com.android.compos APEX. This component is optional and can be included using a makefile.

The security goal is to truthfully compile verified input and produce the output in isolation; Android as an untrusted client can't alter the compilation output in any way other than causing it to fail (when Android falls back to boot time compilation).

The compilation service in the VM generates a signature only if there's no error during the entire compilation. Android can retrieve the public key from the VM for signature verification.

The VM’s key is generated from the VM’s DICE profile, defined by the APEXes and APKs mounted to the VM, in addition to other VM parameters, such as debuggability.

To determine if the public key isn't from an unexpected VM, Android boots the VM to determine if the key is correct. The VM is booted at early boot after each APEX update.

With Protected VM’s Verified Boot, the compilation service runs only verified code. The code can therefore determine to accept only inputs that satisfy certain conditions, for example, accept an input file only where its name and the fs-verity digest are defined in an allowlist.

Any exposed APIs from the VM are attack surfaces. All input files and parameters are assumed to be from an untrusted client, and must be verified and vetted before processing.

Input/output file integrity is verified by the VM, with the files stored on Android as an untrusted file server, as follows:

• 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.
• 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.