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
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
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....
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.
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.
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 ??? ***
*** ??? 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:
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)
- 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 (!)
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....
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...
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.
"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?
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.
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,
, Reason: Fixed date for Frédéric Basse reference. [credit: user Yahoo]
