1. Selver

    OP Selver 13,5,1,14,9,14,7,12,5,19,19
    Member

    Joined:
    Dec 22, 2015
    Messages:
    219
    Country:
    ARM's TrustZone helps make a solid security platform. However, it does not prevent hardware and software bugs.

    The Switch CPU may not be affected by any/all of the below... there's just not enough known about the CPU at this time to know. These are just potential areas of investigation.

    UPDATE: May be a stock NVidia Tegra X1 (Nvidia Tegra T210), per
    https://gbatemp.net/threads/confirm...tock-nvidia-tegra-x1-no-modifications.464725/ which refers to http://techinsights.com/about-techinsights/overview/blog/nintendo-switch-teardown/.
    Now, to determine the revision level

    BL1 := Bootloader that is built into SoC
    BL2 := second-level bootloader
    BL31 := third level bootloader
    EL0 := VM, non-secure
    EL1 := VMs
    EL1S := Secure mode, VM level
    EL2 := Hypervisor
    SoC := System-on-chip
    On October 2016, Frédéric Basse, a security engineer, exploited a bug in the Amlogic S905 processor's implementation of the ARM Trusted Firmware (ATF) reference implementation. Specifically, boot loader 2 (aka BL2, which is loaded by the SoC's bootloader, naturally called BL1) had a bug. BL2 "authenticated" the BL31 image via SHA-256 hash. As the astute reader will note, this is integrity protection, not authentication. As a result, it is now trivial to replace/modify any BL31 image by simply marking it as using SHA-256, calculating the SHA-256 hash, and writing that calculated hash.

    Result: Signed BL2 allows the attacker to load any image they want as BL31 (most privileged code level).
    Source: http://www.fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html
    Impact: None, but confirms that bootloader can still be potential weak point of security chain even when using TrustZone....
    It appears that, if a coprocessor is used and called from secure-mode, it has access to memory at the same privilege level as the caller.

    Thomas Ensergueix, director of product marketing at ARM, ... To maintain security, the coprocessor does not have access to the main memory bus. All data passes through the processor. Ensergueix pointed out that the coprocessor can operate in both secure and non-secure modes depending on the state of the host processor at the time. Thus, any use of the coprocessor from secure mode, although going "through" the processor, is still in secure mode.

    Source: http://www.techdesignforums.com/blog/2016/10/25/arm-trustzone-cortex-m23-m33/
    Impact: Potential weak point of security chain, such as if system uses ARM coprocessor interface from secure mode.
    NOTE: It is unknown if any of these would apply to the Switch processor.
    Hardware has bugs also. Here's some documented ARM Cortex A57 errata as examples.
    Writes to DACR32_EL2 in AArch64 state might not have desired effect on domain settings
    *** ??? Can this result in EL0 processes to access privileged data or code ??? ***
    Cortex-A57 incorrectly allows access to GICv3 common registers in a specific configuration
    Specifically, the General Interrupt Controller v3 allows writes from EL1S and EL2, even when it should not allow such writes, which can occur in the following configuration:
    • ICH_HCR_EL2.TC = 1 (AArch64 Hypervisor Control Register, trap non-secure EL1 access to registers...)
    • SCR_EL3.FIQ = 1 (Secure Configuration Register, FIQ exceptions are taken in Monitor Mode)
    • SCR_EL3.IRQ = 1 (Secure Configuration Register, IRQ exceptions are taken in Monitor Mode)
    In such a case, at least the following GICv3 common registers can be written to from EL1S and EL2:
    • ICC_SGI0R_EL1 == Software Generated Interrupt, Group 0
    • ICC_SGI1R_EL1 == Software Generated Interrupt, Group 1
    • ICC_ASGI1R_EL1 == Software Generated Interrupt, Group 1 (aliased)
    • ICC_CTLR_EL1 == Control Register (!)
    • ICC_DIR_EL1 == Deactivate Register (!)
    • ICC_PMR_EL1 == Priority Mask Register (!)
    • ICC_RPR_EL1 == Running Priority Register (!)
    Result: depends on how the system is implemented, but could be interesting if the pre-requisites are met.
    The security state of memory accesses made by the ARM processor memory system on
    behalf of an external master using the ACP will be same as the security state of the bus
    transaction accessing the ACP. The value of the ARPROT[1] signal read at the ACP
    interface will be used for reads and the value of the AWPROT[1] signal will be used
    for writes.
    Thus, review of all use of / access to the ACP, to understand security context of
    those accesses....
    "To enable low level benchmarking of code, the ARMv6 and ARMv7 applications-grade
    processors include a Performance Monitor in CP15. This hardware unit can be used for
    timing code execution and counting processor events which can occur at run-time, such
    as cache line evictions.
    ...
    To prevent the Performance Monitor being used in attacks against the Secure world
    software, a secure CP15 configuration option can be used to prevent Normal world and
    user mode access to these counters."
    Thus, check if CP15 allows the use of Performance Monitor. Unlikely, but...
    Attackers may abuse bugs in CoreSight debug infrastructure or AXI-to-APB bridge.
    "The parts of the CoreSight infrastructure that are accessible from on-SoC hardware and
    software are implemented as APB peripherals. To reduce the number of components
    needed the CoreSight peripherals are designed not to use the standard per-peripheral
    protection mechanisms provided by an AXI-to-APB bridge; CoreSight components
    should be accessible to Non-secure memory transactions."
    ...
    "In a typical ARM system most peripherals are connected to the APB bus. APB is a
    simpler, lower power, bus than the main AXI bus. The APB protocol does not carry the
    bits related to the TrustZone security state of the bus transactions. This makes it possible
    for existing peripheral designs to used on the AMBA3 APB bus, and places
    *** responsibility for managing the security state onto the AXI-to-APB Bridge *** that
    provides the interface between the high-speed AXI domain and the low-power APB
    domain."
    ...
    Each AXI-to-APB bridge provides an AXI slave interface and can mediate accesses for
    up to 16 peripherals on its local APB bus. The bridge contains address decode logic that
    generates the APB peripheral select based on the incoming AXI transaction. The bridge
    includes a single *** TZPCDECPROT input signal for each peripheral *** that is located on
    the bus. This signal is used to determine if the peripheral is configured as Secure or
    Non-secure; the bridge will reject Non-secure transactions to Secure peripheral address
    ranges."
    Thus, attackers would check protection mechanisms actually used vs. AXI-to-APB bridge,
    with an eye on any inconsistencies, partially-implemented security settings, or the like.
    Since security state management is offloaded to the AXI-to-APB bridge, this seems an
    area ripe for investigation.
    "A consequence of the debug security architecture is that Normal world software may be
    able to directly affect or monitor the Secure world execution in a system when SPIDEN
    or SPNIDEN are asserted. Secure debug should therefore only be enabled when the device
    is located in a trusted environment."
    Thus, can attackers modify these signals without preventing boot from working? Are these even external signals?
    "Systems that want an additional level of protection can use a signal input into the
    processor core to lock-down some of the critical Secure world configuration options in
    CP15. Asserting the CP15SDISABLE processor input signal will cause some of the
    Secure world CP15 settings to become unmodifiable, even if the modification is
    attempted by Secure world privileged software."
    An attacker with hardware access may be able to prevent the SP15SDISABLE input signal
    from being asserted. If the signal cannot be validated as asserted, this may allow
    shack-attacks to effectively disable this layer of security.
     
    Last edited by Selver, Mar 22, 2017 - Reason: Fixed date for Frédéric Basse reference. [credit: user Yahoo]
  2. Selver

    OP Selver 13,5,1,14,9,14,7,12,5,19,19
    Member

    Joined:
    Dec 22, 2015
    Messages:
    219
    Country:
    reserved
     
    adrifcastr likes this.
  3. Selver

    OP Selver 13,5,1,14,9,14,7,12,5,19,19
    Member

    Joined:
    Dec 22, 2015
    Messages:
    219
    Country:
    BTW, feel free to add to this list. Overall, it appears a solid architecture. As seen, some of the possibilities are hardware errata.

    Also, there are unconfirmed reports that the switch has something that prevents downgrade via re-flashing the NAND to a prior firmware.
     
    peteruk likes this.
  4. yahoo

    yahoo G͝B͢A͜t͞em҉p̡ R̨e͢g̷ul̨aŗ
    Member

    Joined:
    Aug 4, 2014
    Messages:
    345
    Country:
    United States
    That date has yet to happen :)
     
  5. Selver

    OP Selver 13,5,1,14,9,14,7,12,5,19,19
    Member

    Joined:
    Dec 22, 2015
    Messages:
    219
    Country:
    Thanks, fixed. :)
     
  6. bennyman123abc

    bennyman123abc GBAtemp Advanced Fan
    Member

    Joined:
    Mar 21, 2013
    Messages:
    918
    Country:
    United States
    Could you link to one or more of these reports?
     
Draft saved Draft deleted
Loading...

Hide similar threads Similar threads with keywords - TrustZone, Gotchas,