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 Definitions 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 Bootloader can still have bugs 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.... ARM Coprocessor Interface 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. ARM Cortex-A57 errata 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. 852523 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 ??? *** 850774 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. Accelerator Coherence Port (ACP) 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 signal read at the ACP interface will be used for reads and the value of the AWPROT signal will be used for writes. Thus, review of all use of / access to the ACP, to understand security context of those accesses.... Abuse of performance monitor "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... Review AXI-to-APB bridge implementation 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. Check if SPIDEN or SPNIDEN can be externally modified "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? Abuse CP15SDISABLE process input signal by tying to ground "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.