 Hello, everyone. It's Bob Waskiewicz from ST Microelectronics, staff engineer with part five of our nine part video series on the STM32L5 trust zone. In part three, we introduced the ARM Cortex M33 trust zone architecture. ST takes that IP from ARM. We've also added our own special things to it because of our background in security and that's what we're going to discuss in part five. The color scheme reminder, green is secure, pink is non-secure. So secure versus non-secure access to memory and peripherals is controlled in multiple places. We've already discussed the IDAU, configured hardware-wise versus the SAU, which is software configurable, but there are also protection controllers out on the AHB bus which also need configuration as well. The global trust zone controller for accessing RAM and external memory, for instance, plus a couple of the peripherals also needs to be configured. So the details of all this is too involved to go into right now. The key point to take away is that if the protection controllers are configured correctly, non-secure code has no access to secure resources. If they are configured incorrectly, secure faults are generated when the secure side tries to access a non-secure device or peripheral memory. This is a reminder summary slide of the trust zone isolation from the previous lecture notes a couple minutes ago, but what's new here is the very bottom comment. All secure registers when access from a non-secure domain are RAZWI. Read as zero, writes ignored. So from a non-secure side, if you ever try to access memory or try to read peripherals or so and it's not configured correctly, you're going to get all zeroes back. If you try to change something, it's just going to be basically ignored. So the protection controllers, as I mentioned, are distributed on different levels inside the flash on the peripheral. This slide is leading us into a discussion of trust zone aware peripherals versus secureable peripherals. So when the TZN equal one bit is said trust zone is enabled, the peripherals are identified as trust zone aware or a secureable peripheral. So trust zone aware is a peripheral that's connected directly to the system bus or the APB peripheral bus and is implementing a specific trust zone behavior. It knows that the trust zone is there. A secureable peripheral is a peripheral as protected by the AHB and the APB and it is controlled by this global trust zone controller. So there's attributes that need to be defined. I'll get into why this is a neat thing in a few slides. So what's trust zone aware? So here's the list. All the GPIO, the global trust zone controller, external memory, DMA, the clock configuration, flash memory on the fly system config, some of the power stuff in the real-time clock. The rest of the peripherals, the I squared C, the SPI, the UART, are secureable peripherals. And what does that mean? So the global trust zone controller is an ST for pi T peripheral. So we came up with this. It configures the SRAM external memories and then all the secureable peripherals. So a secureable peripheral is anything that's not trust zone aware. And it's also responsible for the illegal accesses from the secure side, as well as the secure interrupts. So as seen from the previous table of trust zone aware, the DMA controllers are trust zone aware. They can only be configured by a secure core. They're out on the HB master. What's kind of cool about them is that they support both non-secure and secure transfers independently. So you could theoretically, you could transfer a memory from the secure side to the DMA, and it knows what's secure and what's not secure. I've alluded to this on other slides about this secure, non-secured memory, aliasing. And in a legacy memory map, we have a contiguous memory map from some number to some number. And then within each one, you would take the SAU and you would allocate a region for that. However, because there's a maximum of only eight region, that's kind of very limiting. So ST chose not to do this method. It's unique to ST is that we aliased and have two sets of addresses, one for secure and one for non-secure. And the benefit of this is that, let's say you have four UARTs in a device, which you have in the L5. Because you can configure them and because we can fit them within the SAU regions, let's say I want two of those controllers to be secure and two of them to be non-secure. I can configure them that way. If I dedicate an addressing range to them, then either two are secure or two are non-secure. And if I need four non-secure, I'm not going to be able to do that. So that's one of the advantages of what ST has done in the aliasing of the memory map. All right. So the final word about the SAU, IDAU, and the aliasing of the memory map. The middle column shows the IDAU attributes. So out of reset, this is what you get. So certain areas of SRAM are secure, certain areas are non-secure. The SAU comes along, you decide you want to reallocate flash, you want to reallocate SRAM, you want to reallocate peripherals, and that's how the SAU works. The ultimate final security attribute is based on what's done by the SAU. Thank you for spending your time reviewing part five of the nine-part video series. I encourage you to continue with part six and part seven. Both are hands-on. In part six, we will add a non-secure application to the secure trusted application. And in part seven, I'll show you how to set up the IAR IDE to the bug with symbol data, the two concurrent applications, the non-secure and the secure, using the IAR IDE.