platform_system_core

repository·main·Indexed 22 days ago

https://github.com/aosp-mirror/platform_system_core

Core system components and tools from the AOSP mirror, including bootstat for recording and logging boot event metrics, cli-test for command-line tool integration testing, and fastboot utilities such as the fastboot_fuzzer and Fuzzy Fastboot for automated conformance and penetration testing of device-side fastboot protocol implementations.

Tokens
41.9K
Snippets
90
Records
195
Agent score
79%

What's inside platform_system_core

  1. Overview of Fuzzy Fastboot

    main
    Fuzzy Fastboot (FF) is a standalone automated conformance and penetration testing tool designed to validate device-side fastboot protocol implementations. It is used to identify implementation bugs, ensure conformance to the fastboot specification, and verify that the bootloader safely handles malicious or malformed inputs. The tool is generic and uses an extensible XML configuration file to generate device-specific tests.
  2. Overview of Android's shell and utilities

    main

    Android's command-line environment has evolved from using a custom toolbox binary to primarily using toybox for most utilities. The shell itself has used mksh since IceCreamSandwich.

    Key components include:

    • Shell: mksh (since IceCreamSandwich).
    • Core Utilities: toybox provides the majority of command-line tools.
    • Specialized Tools: Certain commands are provided by specific distributions rather than toybox, such as bzip2 tools, awk (one-true-awk), and bc (Gavin Howard's bc).
    • Legacy/Specific Tools: Some tools like getevent, getprop, setprop, start, and stop are provided by the toolbox binary.
  3. Overview of the Android Init Language

    main

    The Android Init Language is a line-oriented configuration language used to define system behavior. It consists of five main classes of statements:

    1. Actions: Named sequences of commands triggered by specific events.
    2. Commands: Individual instructions executed within actions or services.
    3. Services: Programs launched and optionally restarted by the init process.
    4. Options: Modifiers applied to services to control their execution environment.
    5. Imports: Mechanisms to include other .rc files.

    Syntax Rules

    • Tokens: Separated by whitespace.
    • Escaping: Use C-style backslash (\) to insert whitespace into a token or for line-folding (if \ is the last character on a line).
    • Quoting: Use double quotes ("") to prevent whitespace from breaking text into multiple tokens.
    • Comments: Lines starting with # (leading whitespace allowed) are comments.
    • Property Expansion: System properties can be expanded using ${property.name}. This is useful for concatenation, e.g., import /init.recovery.${ro.hardware}.rc.
    • Sections: Actions and Services implicitly declare new sections. All subsequent commands or options belong to the most recently declared section. Commands/options appearing before any section are ignored.
  4. Overview of Android Live-LocK Daemon (llkd)

    main

    The Android Live-LocK Daemon (llkd) is a component designed to catch and mitigate kernel deadlocks. It provides a default standalone implementation, but developers can also integrate the llkd code into other services as part of a main loop or as a separate thread using the libllkd library.

    llkd uses two primary detection scenarios:

    1. Persistent D or Z state: Monitors threads in uninterruptible sleep (D) or zombie (Z) states. If no progress is made within a specified timeout, llkd kills the process. If the process persists, it triggers a kernel panic to provide a detailed bug report.
    2. Persistent stack signature: (Available on userdebug or eng builds only). Monitors threads for specific kernel symbols in their stack (via /proc/pid/stack). If a listed symbol persists longer than the timeout, llkd kills the process and may trigger a kernel panic.
  5. Overview of libfiemap

    main

    libfiemap is a library designed to create block devices backed by storage in read-write partitions. It is primarily used by gsid to manage Dynamic System Updates. The library works by using libfiemap_writer to allocate large files within a filesystem and then tracking their extents.

    Key use cases include:

    • Creating images that act as block devices (e.g., creating a system_gsi image).
    • Mapping images as block devices while /data is mounted.
    • Mapping images as block devices during first-stage init (using logic similar to dynamic partitions).
  6. Fastboot Protocol Overview

    main

    The fastboot protocol is a host-driven, synchronous mechanism for communicating with bootloaders over USB or Ethernet (TCP/UDP). It is designed to be straightforward to implement across various platforms including Linux, macOS, and Windows.

    USB Requirements

    • Requires two bulk endpoints (in and out).
    • Max Packet Size depends on speed:
      • Full-speed: 64 bytes
      • High-speed: 512 bytes
      • Super Speed: 1024 bytes

    TCP/UDP Requirements

    • The device acts as the server, and the fastboot client acts as the client.
    • The device must be reachable via IP.
  7. Map images as block devices on Metadata Encrypted Devices

    main

    On devices using metadata encryption, /data is mounted from an intermediate dm-default-key device rather than directly from /dev/block/by-name/data. Because the underlying device is not marked as in-use, libfiemap can create new dm-linear devices on top of it.

    In this scenario, the block device for an image consists of a single device-mapper device containing a dm-linear table entry for each extent in the backing file.

  8. How Actions work in the Init Language

    main

    Actions are named sequences of commands triggered by an event. When a trigger matches, the action is added to a execution queue.

    Syntax

    on <trigger> [&& <trigger>]*
           <command>
           <command>

    Execution Flow

    1. Triggers are evaluated. If multiple triggers are joined by &&, all must be true at the moment of the trigger event.
    2. Actions are added to the queue based on the order the file was parsed, then sequentially within the file.
    3. Commands within an action are executed in sequence.

    Important Behaviors

    • Past Events: If a condition (like a property check) becomes true after the trigger event has already occurred, the action will not execute.
    • Async Writes: If ro.property_service.async_persist_writes is true, there is no guaranteed ordering between persistent (persist.*) and non-persistent setprop commands within an action.
    on boot
           setprop a 1
           setprop b 2
    
    on boot && property:true=true
           setprop c 1
           setprop d 2
  9. Understand Android Init triggers and conditions

    main

    Triggers define when an action (a set of commands) should execute. They consist of event triggers and property triggers.

    Trigger Types

    • Event Triggers: Based on boot stages (e.g., early-init, boot). Satisfied when init reaches that stage.
    • Property Triggers: Format property:<name>=<value>. Satisfied when a property matches a value. Use * as a wildcard.

    Combining Triggers

    Multiple triggers can be combined using the && (AND) operator.

    Execution Logic and Nuances

    • One-time check: All property triggers are checked once when the boot event finishes.
    • Property changes: After the one-time check, property:a=b is checked whenever a is created or changed to b.
    • AND logic: For property:a=b && property:c=d, the action triggers if:
      1. Both are true during the one-time check.
      2. a becomes b while c is already d.
      3. c becomes d while a is already b.
    • Event + Property: on property:a=b && post-fs only executes if post-fs is triggered while a is already b. It will NOT trigger if a becomes b after post-fs has already occurred.
  10. How Services work in the Init Language

    main

    Services are programs that init launches and can optionally restart if they exit.

    Syntax

    service <name> <pathname> [ <argument> ]*
           <option>
           <option>
           ...

    Key Constraints

    • Uniqueness: Service names must be unique. If a second service is defined with an existing name, it is ignored and an error is logged.
    • Options: Services are modified by various options (see Service Options Reference) which control capabilities, namespaces, and lifecycle behavior.
  11. Track image mapping state and resource cleanup

    main

    To prevent catastrophic data corruption (e.g., writing to a dm-linear device whose underlying blocks are no longer owned by the original file), libfiemap implements state tracking:

    1. Property Tracking: When mapping an image, a property named gsid.mapped_image.<name> is created and set to the path of the block device.
    2. Dependency Tracking: A status file is created at /metadata/gsi/<subdir>/<name>.status. Each line in this file denotes a dependency on either a device-mapper node or a loop device.
    3. Cleanup: When deleting a block device, the system reads the .status file to ensure all associated resources (loop devices or device-mapper nodes) are properly released.
  12. UDP Protocol v1 Overview and Packet Format

    main

    The Fastboot UDP protocol provides a reliable communication layer over UDP. The device listens on UDP port 5554. Communication is host-driven: the device only sends packets in response to a host packet. If the host does not receive a response within 500ms, it re-transmits.

    Packet Structure

    Each UDP packet follows this format:

    Byte #012 - 34+
    ContentsIDFlagsSeq #Data
    • ID (1 byte):
      • 0x00: Error
      • 0x01: Query
      • 0x02: Initialization
      • 0x03: Fastboot
    • Flags (1 byte): The least significant bit (C) is the continuation flag. If C=1, the data is too large and continues in the next packet. All other bits must be 0.
    • Seq # (2 bytes): A big-endian sequence number. The host increments this by 1 for each new packet. The device must respond with the same sequence number.
    • Data (variable): The payload of the packet.