 Hello everyone, I'm Bob Waskiewicz from ST Microelectronics, staff engineer here with part eight of our nine part video series on the STM32L5 trust zone. We're going to learn a little bit about the additional flash features within the STM32L5 which includes error code correction, dual bank allowing read while write, along with expanding on the option bytes which we've already used to enable the trust zone. We're going to learn about write protection, read protection, and disabling the trust zone. We're going to talk a little bit about faults from the secure and the non-secure perspective and we're going to approach the subject of secure boot, secure firmware updates. Let's talk a little bit about the flash within the L5. As you already are aware, there's two banks of 256K bytes. Bank one and bank two can be configured secure, non-secure, or all non-secure, however you want to do it. The reason for the dual bank allows for the RWW read while write, meaning that if you're executing out of one bank, you can update the other bank without having any stalls. If you try to execute out of the same bank and you have stalls and you have to take into account, interrupts and moves the context to SRAM. So dual bank, there's also error code correction for the flash. So the SEC stands for single error corrected, double error detected. So it'll correct it if it's one bit, two bits, it'll give you an NMI. There is a system flash region, which has a boot loader and this root security services. For those of you familiar with our STM32 loaders, we have some pretty good system loaders for SPI, UR, USB, be it DFU, I2C, CAN. In the L5, they're actually secure now. So that's a whole other lecture series on this root security services. I do have one slide coming next and we'll talk about those. And then we have the option bytes. So we've been playing with the user option bytes and the secure watermark area. There's write protection for when you want to do immutability. There's the secure hide memory area where you can have just one area flash, execute at startup and then go away. There's a true single entry point for secure loaders with the secure boot lock address. And then because it's dual bank, we do have a boot bank swapping bit, which also at times can be handy depending on how you want to do your updates. And then there's others for analog brownout detection, you know, when the voltage gets to a certain point, when to generate the reset and stuff like that. So all this is documented in the reference manual for the L5. So take a look. So what is in this system flash? Well, I alluded on the previous slide to these root security services. So it is a secure set of functions and it's also a secure library. From a secure set of functions, it actually has a unique entry point. It can be entered through software, through a bit setting in the option bytes or through an external IO pin. And it provides services for the SFI, secure firmware injection, which I talked about previously about an hour and 15 minutes ago, in that Q programmer has this SFI interface with the trusted package creator. There's also this SMI interface, which is after the root of trust has been established, you can use this as well to update modules within the application. The RSS is a library, are crypto primitives. We do use AESGCM, we use ECSDA, first changes. But there's also a really unique thing about the L5 known as this RSSE extensions to where there's functions in that root security services that allow you to download your own type of cryptography into SRAM, totally secure. So if you don't like what we did, then you can do your own stuff. There's a bootloader, as I mentioned, with a unique entry point, and then the classic loaders of the USB, SPI, UR, SPI, I2C, and CAN. There's also a provisioning feature within this. We do put a public-private key and we put an SPI certificate in it, which can be used to provision this device. You don't have access to the certificate, you don't have access to the private public key, but the RSS does. So very powerful, doesn't take up any of the Flash allocated for users. So it doesn't affect the 512K of Flash, which we ran our applications in. So this you can read more about it as well in the reference manual, and there's also an application at www.st.com. When I was originally putting together the outline for this virtual hands-on seminar, I was actually thinking of doing an exception hands-on, but I thought that the reversion of the trust zone back turning it off was more important. So I'm going to talk a little bit about this for about 30 seconds and maybe leave this up as an example for you all to do later. But as we know, depending on whether the trust zone enable bit is set or unset, there's either one or two vector tables. So when the trust zone is enabled, we have dual vector tables, and the CPU and memory stack pointer are set for the secure memory, which is at C00000. We saw that in hands-on two and hands-on three on both secure sides. When the security, when the trust zone enable is not set, then this boots just like a normal STM32 Cortex device, which is at 8000, which is where the vector table set, and there's only a single set, one stack pointer and one vector table. So when it comes to interrupting exception handling, each of the interrupts, including the NMI, can be configured by the secure software to target both secure or non-secure states. And we saw that in the hands-on number three when we looked at the non-secure setup at the beginning of time, we passed across the secure fault exception and the global trust zone exception controller. It leads me to this new system exception, which is the secure fault. This is new to the version 8 mainline for handling security violations. So the global trust zone controller is in charge of that. So as you get into the other peripheral configuration, UARTs and I squared season spies and DMA, well, I take the back DMA is trust zone aware. So it's not going to be set up by the global trust zone controller, but any peripheral that is will then be controlled by that. The normal latency for an interrupt in the L5 is just like other Cortex M, which is 12 cycles in and out, including the pushes and pops. So all the context is saved for you. And then chaining, preempting a lower for a higher is six cycles in and out. When we were looking at the return from the memory types, and this was the non-secure callable and secure callable memory accesses. When there's a return from the secure side to service an ISR on the non-secure side, that's when it takes 21 cycles rather than 12 cycles. So I want to point that out to everybody. So whenever you have to service a non-secure interrupt from a secure side, the context security has to be protected. So that takes an extra nine cycles to do that. One final flash memory feature is the readout protection, which we didn't discuss two slides ago. We will actually use RDP level one in a moment when we do the reversion of the trust zone. Typical STM32s have three levels, level zero, level one, level two. From the factory everything is set at level zero, everything is open. Level one is a partial lockdown, as you can read. You're limited in debugging, can't get the flash, can't get to certain SRAM, can't get to certain backup registers. However, you can get to certain system memory registers and you can get to bank memory SRAM one of the SRAM. It's not a total lockdown, but it's a partial lockdown. Level two is a total shutdown. There's OTP, one-time programmable fuses that are blown. The physical pins are broken, physically not connected anymore. So there is no debug of anything internally. In addition to that, there's also option bytes can no longer be changed when you're in RDP level two. So there's also some other certain, some system features that are set as well. In the L5, there was a fourth level added, which we're calling level 0.5. And this allows the non-secured debug when the trust zone is enabled. And two uses for this. One would be you've developed your trust zone, you have all your cryptology, your primitives, your authentication stuff. It's not going to change, it should be immutable. And then you have your developers just develop on the non-secure side creating the application of whatever it's going to be and use it. The second option for this is you develop your own IP, which has some type of SDK software developers kit, API into it. You could theoretically put that into the trust zone side, lock it down, enable debug 0.5, send that out to your customers and they could debug or they could develop with your IP, debug it and never get into your IP. So there are the features. Level 1 can be reverted, as I mentioned, level 0.5 can be reverted as well. And when those reversions occur, there's a total mass erase of all the flash internally. We're going to use level 1 in a few slides to turn off the trust zone and revert back to a non-trust zone device. Prior to the STM3205, ST developed and has released our secure boot non-secure firmware update application. It covers a majority of our families, the L4, F4, F7, H7, G0, G4. And it uses those physical security features for isolation, which we talked about an hour and a half ago now. You know, when we're talking about the MPU or talking about hide memory and we're talking about the firewall. Level 0.5 has the trust zone, so it lends itself very well to a good security device. For, remember also I mentioned about the type of attacks, remote versus chip level versus board level attacks. So from the remote attacks, which are mostly 95% of the attacks today, the L5 is an excellent chip. We've created the SBSFU based on the ARM PFM, which is the trusted firmware architecture for the Cortex-M devices. And that's been released. It's actually in the Cube L5 that you may have already downloaded. If not, it's on the Discovery Board BST, and it's in the applications folder. So take a look at that. There's users manuals, explains it all. But this is the foundation that you would use on the trusted side, and then there's a non-secure application that it calls as well. It's a UART using a Y modem. It allows you to give you an idea of what you can do with it. Along those lines of the SBSFU and the TFM architecture, ST has obtained PSA Level 2, which is physical security architecture criteria from ARM. And that certification, we were the first to certify the PSA Level 2 of anybody, and the L5 was the one that did it on February 10th of this year. So this concludes the lecture part of the hands-on seminar. What we're going to do next is go into hands-on number four, and we're going to do the reversion of the trust zone. Thank you for taking the time to learn more about the flash features, which enhance the trust zone, the fault generation of the trust zone. I did not include the deactivation slides in this lecture portion of the nine-part video series. I moved those into part nine, the hands-on, because that makes more sense to actually learn the methods and then do the methods. So I encourage you to continue with the final video nine, which will deactivate the trust zone, which was enabled back during the second hands-on video.