Skip to content
Snippets Groups Projects
  • Mark Salyzyn's avatar
    397b07b3
    bootstat: lock down *_boot_reason_prop · 397b07b3
    Mark Salyzyn authored
    Add series of neverallow rules to restrict components from reading or
    writing bootloader_boot_reason_prop, system_boot_reason_prop and
    last_boot_reason_prop to trusted set of domains.
    
    The policy is that bootloader_boot_reason_prop (ro.boot.bootreason)
    has a compliance issue due to the sheer momentum of near unparseable
    content as filed by the wide variety (8000 different devices at last
    count) bootloaders and is only to be accessible to a series of
    responsible system components.  It can be inaccurate as it provides
    no means to evaluate a shutdown, likely reporting "cold" (from
    initial power up) or the more generic "reboot".
    
    The last_boot_reason_prop (persist.sys.boot.reason) contains
    inaccurate information as it is only valid after a controlled reboot
    or shutdown.  The value can linger around after less controlled
    scenarios.  Since the information could be false, we do not want to
    support it as an open API, so we again block access to only
    responsible components.
    
    The system_boot_reason_prop (sys.boot.reason) is a canonical boot
    reason that takes into account parsing bootloader_boot_reason_prop,
    boot_loader_boot_reason_prop and other system and HAL generated hints
    to determine a parseable and most accurate reason for the last time
    the system was rebooted.
    
    For now the policy for system_boot_reason_prop is to audit users of
    the API, and on a need to know basis via device additions to the
    selinux rules.  If vendors need their components to access the boot
    reason, they need to comply first with CTS tests and spirit with
    regards to controlled reboot messaging and in turn read the
    system_boot_reason_prop for the canonical information.  It will
    contain validated content derived from bootloader_boot_reason_prop
    in the scenarios that count.
    
    The controlled reboot APIs include:
    - android_reboot(ANDROID_RB_<TYPE>, int flag, const char* reason)
    - PowerManagerService.lowLevelShutdown(String reason);
    - PowerManagerService.lowLevelReboot(String reason);
    - ShutdownThread.shutdown(context, String reason, boolean confirm);
    - ShutdownThread.reboot(context, String reason, boolean confirm);
    - PowerManager.shutdown(boolean confirm, String reason, boolean wait);
    - PowerManager.reboot(String reason);
    
    Any others (including the direct linux reboot syscall) create
    problems for generating an accurate canonical boot reason.
    
    Test: compile
    Bug: 63736262
    Bug: 65686279
    Change-Id: I2e5e55bbea1c383c06472eb2989237cfeb852030
    397b07b3
    History
    bootstat: lock down *_boot_reason_prop
    Mark Salyzyn authored
    Add series of neverallow rules to restrict components from reading or
    writing bootloader_boot_reason_prop, system_boot_reason_prop and
    last_boot_reason_prop to trusted set of domains.
    
    The policy is that bootloader_boot_reason_prop (ro.boot.bootreason)
    has a compliance issue due to the sheer momentum of near unparseable
    content as filed by the wide variety (8000 different devices at last
    count) bootloaders and is only to be accessible to a series of
    responsible system components.  It can be inaccurate as it provides
    no means to evaluate a shutdown, likely reporting "cold" (from
    initial power up) or the more generic "reboot".
    
    The last_boot_reason_prop (persist.sys.boot.reason) contains
    inaccurate information as it is only valid after a controlled reboot
    or shutdown.  The value can linger around after less controlled
    scenarios.  Since the information could be false, we do not want to
    support it as an open API, so we again block access to only
    responsible components.
    
    The system_boot_reason_prop (sys.boot.reason) is a canonical boot
    reason that takes into account parsing bootloader_boot_reason_prop,
    boot_loader_boot_reason_prop and other system and HAL generated hints
    to determine a parseable and most accurate reason for the last time
    the system was rebooted.
    
    For now the policy for system_boot_reason_prop is to audit users of
    the API, and on a need to know basis via device additions to the
    selinux rules.  If vendors need their components to access the boot
    reason, they need to comply first with CTS tests and spirit with
    regards to controlled reboot messaging and in turn read the
    system_boot_reason_prop for the canonical information.  It will
    contain validated content derived from bootloader_boot_reason_prop
    in the scenarios that count.
    
    The controlled reboot APIs include:
    - android_reboot(ANDROID_RB_<TYPE>, int flag, const char* reason)
    - PowerManagerService.lowLevelShutdown(String reason);
    - PowerManagerService.lowLevelReboot(String reason);
    - ShutdownThread.shutdown(context, String reason, boolean confirm);
    - ShutdownThread.reboot(context, String reason, boolean confirm);
    - PowerManager.shutdown(boolean confirm, String reason, boolean wait);
    - PowerManager.reboot(String reason);
    
    Any others (including the direct linux reboot syscall) create
    problems for generating an accurate canonical boot reason.
    
    Test: compile
    Bug: 63736262
    Bug: 65686279
    Change-Id: I2e5e55bbea1c383c06472eb2989237cfeb852030