-
Notifications
You must be signed in to change notification settings - Fork 0
Result
If you still have problemes after reading that, take a look at the Trouble-Shooting-Guide
We wanted to build a demonstrator that shows a feature from the PSA. Wehad the choice between the IDAU/SAU or the GTZC.
The security of the hardware is based on the separation of Secure- (S) and Non-Secure (NS) areas. (see also Docs, section 5.2)
Functions and data from the secure area cannot be used by functions of the Non-Secure sections (at least not ad hoc).
We have chosen for now the GTZC (Global-TrustZone-Controller). (the decision can be tracked in #60, but also in #54, #70, #65, #35,#36, #57) The GTZC is concerned with the separation of the GPIO between Non-Secure and Secure.
The project can roughly be divided in two pieces:
There are 3 LED's present on the board, each for one color dimension.
Additionally, there is a 12v RGB strip controlled by the p9813. (see also Startup#LEDs).
The strip is controlled by the P9813Controller.
Both variants were summarized in the LEDController. This controller can only be used everywhere, if TZ is disabled. If TZ is enabled, only the functions reachable from Secure and NonSecureCallable (marked through secureportNON_SECURE_CALLABLE) can be called. The GPIO Pins cannot be used directly from NS, as the pins are marked as secure during initialization (therfore, the GTZC blocks the usage).
In order to design the demonstrator more interactive we chose to create the attack after the user pushed the blue USER button. We explained how to enable interrupts in the section about STM32CubeIDE. Besides enabling the interrupt and disable some features of CMSIS (see section about FreeRTOS, "Creation of Tasks") we manually created a thread. This Thread was handwritten, as auto-generated threads are created before the Scheduler of FreeRTOS starts. The thread tries to toggle the leds which are marked marked as secure (see above) via a nonsecure function (BSP_LED_Toggle which mainly controls HAL_GPIO_TogglePin).
Note: As the LEDController needs to be marked as secure it is in the current project not implemented that the attack affects the RGB Strip as well. One could make this work pretty easy on the project where TZ is disabled, but to make it work wit TZ enabled is not as easy. This might be a further issue another group could work on. Nonetheless, everything works fine with the onboard LEDs.
To check that the board is actually running correctly and doesn't run into any faults there are two autmatically generated threads which toggle the green and blue LED through a NSC-Function. It is required to call osDelay after every function call to make sure the LEDs are actually blinking and are not permanently on.