Presentation on theme: "Android-IA Scalability Features To Support A Single Build Target"— Presentation transcript:
1Android-IA Scalability Features To Support A Single Build Target Andrew BoieJianxun “Chang” ZhangDaniel LeungCharlie JohnsonMatt GumbelAndy RossAndroid-IA Scalability Features To Support A Single Build Target
2Android-IA on 01.org - Who We Are https://01.org/android-ia/Part of the larger 01.org website maintained by Intel Open Source Technology CenterIndependent Android community site dedicated to driving Android support and innovation on Intel ArchitectureBinaries and source code availableCode for all the topics covered today available onlineUltimate objective of most of our IA enabling and innovation is upstream inclusion in Android Open Source Project (AOSP)Join our mailing list!
3Single Build Target Objective Run Android at some baseline level of functionality on multiple devices with a single binary installation imageAdvantagesReduce the number of hard-coded parameters in the Android board configuration filesSupport many off-the-shelf devices, including ones we don’t know aboutReduce bring-up time on new platformsTarget a class of devices instead of a specific deviceLowers expertise required to bring up Android on a systemScalability May Not Be For EveryoneA single image may make it more difficult to optimize for a specific device without breaking something elseRequires testing on all devices with any changeAs opposed to just the specific device being targeted
4Three Classes of Parameters Build-time configurationMuch of Android is done hereImage is highly tuned to specific destination hardwareInstall-time configurationDecisions made when software is installedStored outside scope of software updatesOnce selected, can’t easily be changed/factory/factory.propSet of read-only Android system propertiesScope limited to properties that are not auto-detectable or runtime immutableCamera physical orientationLCD density (EDID-based config in future)Runtime configurationAutomatic detection of parametersManual selection, i.e. Settings appAndroid PackageManager imposes some constraintsStrange things can happenro.sf.lcd_density
5Automatic Kernel Module Loading Modprobe-like library functionsinsmod_by_dep() and rmmod_by_dep() added to libcutilsTraverse modules.dep dependency hierarchy to insert all needed dependenciesSystem-wide and local blacklists can be used to skip loading particular modulesrmmod_by_dep() won’t remove a dependency if used by something elseUses modules.alias to map uevent modalias to the module nameEnhance ueventdMany uevents may come in before /system is mounted, queue themDeferred processing until /system is availableAdditional init.rc commandscoldboot – trigger ueventd deferred module loading by triggering ‘add’ events in sysfsprobemod – improved ‘insmod’; inserts required dependencies/sbin/modprobeDrivers in kernel can request modules by launching a programDefault to /sbin/modprobe; thin wrapper around insmod_by_dep()Not actually kernel.org GPL Modprobe
6Automatic Module Loading (cont.) Loading appropriate WiFi DriversAudio codecsUSB peripheralsCamera Hardware, uvcvideoNot everything can be auto-inserted yetCurrently building-in USB Ethernet and USB Serial drivers for alternate ramdisk targetsNo /system available in Recovery ConsoleSensor Hub drivers currently don’t probe available hardwareModules that require parameters must be inserted via init.rcNo modules.conf (yet)Plan is to upstream to AOSP soonhttps://01.org/android-ia/blogs/jzhang80/2012/increasing-android-device-scalability-automatic-kernel-module-loading
7Flexible Disk Installer “Iago” Not really applicable to handset/low-end tablet productsReplaces old bootable/diskinstallerBuggy, not flexible, MBR/GRUB onlyUse-casesInstall on Android on commodity hardwareIncluding devices not previously knownDual/Multi boot with other OSesProvision hardware that can boot from external mediaAutomatic installer which uses predefined configurationInteractive installerInstallation questions to customize to user’s needsLive Android session directly from the USB stickGraphics driver selection (WIP)
8Flexible Disk Installer “Iago” Design goals:Lightweight integration into Android treePulls in parted, ntfs-3g, efibootmgrParted eventually going away in favor of custom GPT librarySupport for platform-specific plug-ins similar to Recovery/OTA systemInteractive disk partitioningDual Boot supportGPT/UEFI support (Legacy BIOS/MBR support dropped)
9Flexible Disk Installer “Iago” Query user for configuration parametersInstall-time configuration parameters established hereSelections written to /factory/factory.prop, never touched by OTA or Factory Data ResetEventual support for Multi-BootCurrently support dual boot with Windows 8Ubuntu, Fedora, Tizen, multiple Android installsEventual support for a GUIInstallation media boots into Live Android imageInstaller frontend a special app that only exists in Live image
10SMBIOS PropertiesSpecial case of install-time parameters for known devicesSystem Management BIOS (SMBIOS) specificationMicrosoft requires OEMs to support this for certification, all Intel devices that can run Windows should have itDMI sysfs/sys/device/virtual/dmi/idUnique modalias per deviceSearch for substrings in modalias for manufacturer and model information/system/etc/dmi-machine.confIndividual system property files in /system/etc/machine-props/Parameters must be known a priori, but can be updated OTADevices that aren’t supported instead configured by Installer questions
11Disk Layout Scalability Disk information hardcoded in lots of placesrecovery.fstab, vold.conf, init.rc or mountall fstab, OTA scripts, others…Establish /dev/block/by-name symlinks so files are staticAs opposed to /dev/block/sda5 (example)/dev/block/by-name/systemIago installer places partition names in GPT entriesPrefixed with randomly generated “install id”Prevents issues with multiple Android installations on same device (Live image)Modification to ueventd to create symlinks based on names passed in via block device ueventsMany shipping Android devices do something similarPartition name stored in the GPTInclude hard-coded controller name in path for security reasonsparse_platform_block_device() in ueventdOtherwise, possible to spoof partitions using specially crafted GPT in removable mediaAdvantagesHardcoded files in build written once and never touched againPhysical disk configuration completely flexible, even span multiple disksNo Installer support yet, but could conceivably support things like LVM, SW RAID, etc.Can install Android on removable mediaBut if security (user is enemy) is a concern don’t do this!
12Device TriggersSometimes need for more complicated processing on device insertionUeventd only has limited functionalityCreation of device nodesPermissions on device nodes based on ueventd.rcAutomatic insertion of modules and their dependencies based on modalias/modules.depExtend init.rc syntaxPerform additional actions when a device is added or removedExample: bring up network interface when USB Ethernet adapter is connectedWorking with Google on acceptable upstream implementation
13Scalable HALs Audio HAL Sensors Camera HAL Extension of Nexus 7 Audio HALAt boot time, probe attached audio codecsConfigure mixer controls appropriatelyNo standard set of names for mixer controlsSet of XML files for each codec vendor familySo far Realtek & Cirrus Logic (most common)Can add new ones without modifying HAL codeSensorsCheck for industry-standard IIO Sensor Hub at first bootSlightly time-consuming, cache the result for later bootsWe expect most Win-8 class slates to have this hubCamera HALSupport various USB cameras using Video4Linux interfacesPhysical layout specified in ro.camera.* properties
14Secure Boot Prevent all unauthorized Ring 0 code from running EFI binariesLinux kernelRamdiskKernel ModulesProvide facilities for the user to enroll their own certificates/hashesViruses/Malware are the enemy, not the userMinimize key storage locationsAs much as possible, rely on the BIOS for this stuffDo not implement our own key managementBuild on Android model of production key custodianshipDon’t impose large changes on AOSP componentsUpstream what we do change
15Secure Boot Few requirements from Google on this topic No requirement for hardware rooted verified/measured boot for foreseeable futureWideVine DRM, GMS does not require itGoogle only has some unlock requirements for Nexus lead vehiclesBootloader unlock/re-lock feature/data wipe on bootloader unlockSecure boot requirements typically originate from mobile carriersSome OEMs may feel that their revenue stream may in part depend on the specific software they provide for their hardwareTwo ‘flavors’ of Secure Boot:Secure Boot – viruses/malware are the enemy, user still in controlRestricted Boot – end user is additionally the enemyNeed to educate OEMs that they can still choose to keep the user in control!
16FIRMWARE EFI BIOS EFI SYSTEM PARTITION OTHER PARTITIONS ‘boot’ /system DBDBXMokListEFI SYSTEMPARTITIONShim Lock ProtocolshimGummiBootMokManagerWindows Boot ManagerOTHER PARTITIONSHeaderbzImageRamdiskSignature‘boot’HeaderbzImageRamdiskSignatureHeaderbzImageRamdiskSignature/system.ko Modules‘recovery’‘fastboot’
17Ethernet Connectivity Desirable for a few reasonsDevices without WiFiADB/GDB over Ethernet for devices without USB OTGPerformance throughputConfigurationExtended the Android Settings appDHCP or Static IP configurationProxiesStatus bar icon similar to WiFiIntegrated with Android ConnectivityManagerSwitches lower priority networks off when higher priority connections are availableEthernetManager not exposed directly to appsApps just see it as a generic network connection like WiFi or 3GUtility configurationUse Ethernet as secondary network interface for debugAllows Ethernet connectivity in alternate ramdisksAlso during bringup when UI isn’t yet workinghttps://01.org/android-ia/blogs/mkgumbel/2013/ethernet-support-android-ia
19Droidboot Traditionally, Fastboot implemented in bootloader Reference implementation in LK BootloaderNeed to re-implement with every bootloader changeImplemented as a tertiary boot targetAdditional boot image with special ramdiskSimilar to Recovery ConsolePlug-in architectureSimilar to Recovery Console plug-insAdd platform-specific flashing commandsUpdate device firmware, baseband, BIOS, etcUses recovery.fstab to map device nodesFull Android userspace is niceShell commands, libz, availableOn-the-fly gzip decompressionEthernet connectivityHowever, with migration to UEFI, plan is to re-implement as UEFI application which can be baked into firmwareGoogle likes this better because it will be always available
20Future Work Framework overlay scalability Fastboot as EFI application Cyanogenmod has some work in this spaceFastboot as EFI applicationMore Installer plug-insIntegration of Sony DASH Dynamic Sensor HALMultiple graphics driver supportInstall-time App specification
22Release Key Management Internal access to production private keys is very strictly controlledPrevent key leaksPrevent creation of unauthorized SW which could run on consumer devicesTypically only a very small set of individuals have accessHowever, developers need to be able to create and test their builds with security enabled!
23sign_target_files_apks Google design is to use testing keys in the codebase, and replace laterTesting keys committed to source code repositorySystem APKs (Android app bundles) signed with testing keysCertificate in Recovery Console initrd to verify signed OTA updatesCTS fails if testing keys are detectedTarget Files Package (TFP)Build artifact containing all release binariesTools to create OTA updates from a TFPsign_target_files_apksStandalone tool to create new TFP from old, re-signing everythingUsed by release team, could also be part of a remote signing infrastructureRe-signs all APKs with production keysReplaces OTA key in Recovery Console initrd with production versionFor boot security, let’s build on this…
24sign_target_files_apks Extensions Testing PK/DB/KEK/shim keys checked into the buildDevelopment/prototype HW should have testing keys in BIOSEFITools “Lockdown.efi” in installation media can provision keys and enable Secure Boot if BIOS is put in Setup ModeFor production releasesRe-sign Linux kernel modulesRemove old testing sig, re-sign with production DB keyRe-sign AOSP boot imagesMust do this after Recovery initrd key has been swappedRe-sign bootloader EFI applicationsTool to create secure provisioning image from TFP
25Release Workflow Android Build TFP Source SW TFP (Test Keys) Optional, to createIncremental updateTFP(Test Keys)Source SW TFPGenerate SW UpdateSW UpdateRe-SignSigned TFPA TFP is a “Target Files Package” which is a zip file containing the entire deliverable state for a particular SW build. TFP are used as input files when creating SW update packages; incremental SW updates use two of them for the source and target SW versions.A TFP is created by the build with everything signed by the “testing” keys; in order to use production keys, the sign_target_files_apks tool is used to substitute the real keys for the testing ones.Generation of SW updates (ota_from_target_files) takes a couple of options. There are flags to disable rollback protection (which enforces that full updates must be only applied against an earlier SW version), create incremental update (from a second TFP), force an erasure of /data, etc.sign_target_files_apksota_from_target_filesCreate Provisioning ImageUSB Provisioning Image