 Okay folks, we can finally get started. Sorry for the technical difficulties and we still kind of have a little bit of the edge off But we'll be okay. I'm Andy Gross. I work for Lenaro. I'm part of the light team which deals primarily with IOT devices And for the past gosh six nine months something like that. I've been working on Zephyr for some of the ARM V8M support and some of the Security changes that came in before the ARM V8M work Some of the user space stuff So you'll see a notice and a nice abrupt change to the template I only kept the front slide to the to their template and then switch back to a Zephyr one But but anyway the agenda for today. I'm going to talk a little bit about what T means for microcontrollers We'll talk a little bit about the hardware requirements that you you may need for implementation of execution environment I'll talk about the Zephyr support specifically for ARM V8M and there'll be a little bit of a v7m Information as well because we do have some configurations where people want to have multiple cores doing a trusted execution environment versus an ARM V8M and I'll touch on the multiple image complications, which if you were able to attend David Brown's Presentation yesterday about MCU boot this also touches on some of the things that he brought up in his talk And then we'll talk about some of the current work items things that are coming down the pipes that are that are actively being worked today So trusted execution environments, you know, there are some solutions that are currently out there in the ecosystem Synopsis has their secure shield for their arc processors. They are currently working on adding support into Zephyr for that We have the TFM, which is the arm-trusted firmware for Cortex-M and then there's also some proprietary Multi-core solutions out there one good example is probably the Cypress PSock they have a multi-core with a I think it's an M0 that's designated as a security processor and they have some IPC where they go back and forth to do Calls to do certain secure functions and then there's probably some other ones out there that people have Have proprietary designs for So fundamentally when it comes down to it What are we trying to do? We're trying to keep from leaking information and that can mean a lot of things you know, whether it's a key or a Cert that you have stored off somewhere some information. You don't want Accessible from you know applications you may want to do something with the information But you don't want to expose it directly and that's really what all this is about. So how can this be done? So Arm v8m came out with a solution where they've They've added some they've separated some environments. There's a secure in a non-secure environment And you can actually divvy up the resources on the board, whether it be the flash the RAM the peripherals And only have access from secure or non-secure If you're running non-secure you you can't access the secure components if you do you get a fault This requires some access controls on the peripherals and also on the memory space So you you can kind of think of it somewhat like a memory protection unit except maybe Extended a little bit But for the peripherals you can actually flag a peripheral is being Owned by the secure or the non-secure and if you try to access it, of course, you'll get a fault For arm v7m. However people do this you through the use of multiple cores and So what you have is you actually have a physical separation of the peripheral and they may be on the same chip But one core may have its own memory and flash and the other core may have its own and you may have some IPC So if you're talking to the secure processor, it has its own set of resources that are not directly accessible by the non-secure Processor and that's how they do that. You may have some shared memory and things that you can use for your IPC, but Primarily you're going to be storing your secrets off on the secure processors resources So touching a little bit on the arm v8m specific hardware. So the things that they added So there's two types or two versions of arm v8m. There's the main line and the baseline And there's also what they call security extensions So the main line is a v7m compatible Processor the baseline is a v6m the differences are There's some instructions set differences And I think the v8m supports DSP extension and Gosh, I can't think of anything else, but there are a few other small differences So they added the secure non-secure environment They're already existed a privileged and non-privileged mode and this is true on the v7m and v8m And I think it's also an option in v6m if you if you have that extension They added a security attribution unit and this is where you can actually specify memory ranges flash peripheral address space you can actually set this to be accessible by one or the other and actually actually also set the Read write access permissions If you're a sock vendor You can implement an IDAU which is the implementation defined attribution unit So that's just taking it's like an SAU. It's just implementation specific for that chip for what the sock vendor wants to do and then there's also some Memory protection units that were added. I believe they're optional But you have an MPU on the non-secure side and you also have an MPU on the secure side And they use that I'll get to that But you can use the MPUs to firewall off some of the secure areas if you want to actually partition your secure Execution environment into multiple partitions So Zephyr support currently as it stands Nordic did a bunch of work in getting the base architecture support for the baseline and mainline in So baseline is the M23 mainline is the M33 if you hear people talk about these that's what they mean by them There's support for the memory protection unit and also what was really nice Arm did two things one they fixed their memory protection unit to be a little bit more user friendly In the v7m and any sock manufacturer who decided to use the base vanilla arm implementation It required power of two regions, which is very It's a pain What that meant is not only did you have to size your things by power of two You also had to actually start your region on a power of two and if you weren't careful Things could actually slide into an area where it actually wasn't covered by your region And that could either open up things to be accessed by Non-secure or you could very easily exceed that and fault thinking that you're doing the right thing The other thing that they did was is instead of using one of the regions for a stack limit Which is what we do currently on the v7m They added a stack limit register, which I believe is optional But it's really nice because when you're when you're running you just set the stack limit That will actually do the protection of your of your stack for you instead of having to deal with the protection unit So that's pretty nice The other thing that was added support for the MC MSE which is the security extensions You have to use a new newer compiler that actually has the Support for that and it's the option is that dash MC MSE and if you pick up one of the arm GCC compilers, I think it's 2017 q4 or newer you'll have support for that if you want to play around with it Where this comes in is is that if you want to create the veneers or Some of the security features you have to use that option the reason why is because they added an extra Linker region that's called the secure non-secure callable And what that allows you to do is when you actually do your transitions from Non-secure to secure you have some Rappers that are that are built in that area where you you jump into that and then that allows you to jump into the secure execution environment Another thing that was added was the secure library stub creation So if you've gone out and looked at TFM or looked at zephyr when you want to run an Environment where you have a non-secure and a secure image if you want to do secure functions You actually have to create a stub. This is the thing that allows you to actually progress across the boundaries There is support in zephyr to create that and I'll kind of talk in the next few slides about You know well You have a lot of choices when you decide what you want your secure code to be you can use TFM You can use zephyr if you really wanted to or you could just write your own But there are some specific things that you have to take into account if you do that Lastly we have some SDK work in progress So with the change in the compiler the current zephyr SDKs don't have a compiler that supports this So you either have two choices. Well, yeah, you have one choice You have to use an external compiler. We don't want that to be the case We want an SDK update and we want people to be able to pull that down and just use it like they would today with zephyr We don't want people to have to go around and try to find tool chains So I'm going to touch on the next three slides are going to touch on how how arm at least in the past and even in the present kind of describes how these systems are going to be Set up and this will become clear a little bit later I think when we start to talk about how the system works together So if you've gone to any of the arm presentations, they'll talk about level one level two level three of of PSA And what that means is is that if if you're running arm v8m and even if you're not really but this slide shows an arm v8m You're going to have a separation in the system You're going to have some some user application code Which is going to run in non-secure and then you're going to have a secure image that's running on The side that has some set of functions that you want to you want to actually do that may be You may have some resources over there like a key You want to make calls over to encrypt some some information? You may want to sign something The the hash line and the center is the separation between the two on an arm v8m This is a context which this isn't actually IPC. I think PSA now specifies that it's IPC, but That on the same processors. That's kind of that's kind of an odd thing to do But in level one what happens is you have your non-secure application on the left You have all the secure functionality on the right and there's no separation between any of the secure partitions So there they all have access to the same resources an SPE is a secure Processing process environment the SPM is the secure partition manager The SPM is supposed to be the one that when you switch context sets up all the security the way that you want it to be If you transition to a level 2 you'll see now that there's a separation between the SPM and all the secure functions And then if you take it even further You may have separation between all of the secure partitions or the secure functions And I think yesterday if you went to The presentation you would have seen the arm presentation you would have seen something similar to this so When we were talking about the hardware before I mentioned the MP use And the SA use and the ID a use When you are actually firewalling off these things on the right? I think this is where the MP use probably going to come in on some of these things You're gonna want to set this up to actually separate some out some of the partitions and when you're running in one context versus another And when I'm saying context, I mean even within the secure context you may be running on one of these functions You only have access to a certain amount of the resources Now currently in the TFM. We only have support for level one So when you do the transition everything on the secure side you have access to everything So that's something to keep in mind now in the future. I think they're gonna be adding in support for these other these other levels So in a single core implementation And this is true today in Zephyr if you if you try to run this This is an R&B 8m. You're gonna have your application code. You're gonna have some API that you're gonna call that needs to call down into what what are called the What a lot of people call the veneers, but really they're stubs Those stubs reside in the secure non-secure callable region. That's When you go down the stack you eventually reach the point where you actually make the transition across and you access one of the SPEs Once you're on the other side the code on the other side does whatever function you want it to do In the current TFM. This is a blocking Synchronous call so You make the call it runs to completion you come back if you do something that that takes a long time well too bad and in one of our Current boards that we have that runs fairly slow We were doing something it was taking seconds and then of course you get back and your your cystic is completely wrong So so yeah, that that needs to be dealt with and I think in the future There's gonna be some improvement there to deal with that because I mean we're talking about an RTOS and making these synchronous calls You can't block for a long period of time You have to actually deal with other things and it's if you have things you need to deal with then you have to start thinking Well, then I have to start switching or moving things over to the other side because you know, it's able to handle them so so yeah, those changes need to be made and and this was something that was brought up in Lenaro connect I think in one of the arm presentations I'll say now if you guys haven't seen some of the presentations the previous ones or even the one yesterday from arm Please visit them and and check them out. There's a lot of information in these that's very useful to understand how some of these things work So in a multicore implementation Which this this is also being worked on right now It's very similar the difference is instead of having a context switch on the same processor. You actually have Open amp on the bottom with The stub is gonna the API is gonna be the same But once you get below that instead of doing the stub and doing the transition to the different context You're actually doing an IPC call across open amp, which utilizes some some mailbox Hardware and maybe some shared memory This would be true whether For the multicore and this is something where I think we have one of our boards that has to m33's on it We're gonna be modeling that We do have some current v7m hardware the psox 6 Which we're gonna be doing the same thing So the idea is is that tfm is gonna run on not only rm v8m But also run on v7m as well the only difference of course is gonna be how you do your transition so Going past some of the architecture and how things are gonna work When you actually create your images you run into kind of one of the first problems, which is Okay, how do I load the system? If you're running secure and non-secure you have two binaries so That means you have to you have one you have to have a bootloader So regardless of whether or not you're gonna use tfm on the secure side you have to have a bootloader The other thing you have to have is you have to actually implement some of the security configurations but so Today when you build a zephyr You can build zephyr to run secure single image and you can load it and run it just fine without any bootloader anything You're not getting the full Benefit of having the separation and the application being on the non-secure side and The other things running on the secure side, but you can do it if you decide to run a secure and non-secure image You have two binaries you have to Package them together in a way that both sides know where everything is and and what this means is is that on an RV 8m the way the Address map works is is that you actually have aliases that specify whether or not it's a secure and non-secure address space So every one of the peripherals and RAM and flash has two addresses There's a non-secure in the secure When you start to divvy up your flash and RAM You actually have to say okay Well, how much of my flash do I want for secure and how much do I want for non-secure? You lay it out in your in your in your address map and then For the secure side you have to start at those addresses for the non-secure side when you actually do the jump to the non-secure You have to know what that address is and not only that the non-secure application Zephyr has to know what that address is Today we currently Describe this in DTS. So if you go to Zephyr and you look at any one of the the the boards You'll see that it has device tree file that'll contain a RAM flash peripheral address map This isn't going to be any different for arm v8m. The the complexity is is that Whatever you describe or use on the secure side You also have to describe and use on the non-secure side using different address number Different address ranges and not only that different offsets So if you set aside, let's say 32k of ram for secure and let's say you have 96k of ram for non-secure The the non-secure side is not only going to be a different address It's going to be offset into that 32k into the RAM And if you set up your your configuration in a specific way If you don't do that properly One of two things happens either you get lucky and you you somehow manage to get an address that you can use or you You you have a violation and you get a fault And you don't get very useful information back. The system just it you stop Um, so that's that's not very useful So one of the problems that we have is we have to have a coherent description of the hardware On the Zephyr side, we already use dt. Um, we want to Use device tree also in the tfm to describe this And we want to use the same dts And one of the things that's one of the changes that's come in recently was support for the ranges property And if you're familiar with dts, that's great. If not Dts just allows you to describe your hardware. Um, the ranges property actually allows you to Map the address based on some rules So we can actually describe the hardware the complete hardware using one device tree file But we can generate two outputs based off of whether or not it's secure and non-secure So that's good. Um When an application developer decides how they want to divvy up the resources That comes into play You have to figure out which peripherals are owned by which Divvy up your flash and ram and all the numbers have to have to match up Um one nice thing about using the same file Um with the outputs we can actually compare them and make sure that there's no overlap That will save users a lot of problems So this is one of the things that's currently in work So to touch on all the items that we currently have You know in in progress, uh, there's some prs out there for Muska support those still need I think there's still a few comments that are outstanding Um, we're adding support for the mps2 if you don't know what that is That's one of the arm development boards that has an fpga on it It allows you to load different models so you can actually run more than just the m33 or m23 you can run A lot of other processors We have multi-core work going in on both the v7m and v8m side There's a group or Some individuals in light that are working on open amp. We have one guy working on the ipc for the v7m And we're going to be spooling up The v8m work since we do currently have a board that has two m33s on it There's ongoing work with the device tree Once we get that gets that that'll be put in place about at the same time that the musk is because those two are kind of Stuck together And then we have some of the tfm improvements that we want to do So tfm right now it's it's it's in its early stages There's Some some things that can be added changed improved Some of the things that we have to kind of wrangle our heads around is Some of the secure functions and kind of making it a little bit more modular Ideally from a zephyr perspective. We'd really like to Perhaps use zephyr without the scheduler and without some of the pieces as the core and then add in some of these tfm components and and that would be our secure image The tfm today I'm not sure if it really needs some os primitives But if it gets to the point where they do You know, you're going to have to have a selection of some some r-toss that acts as the the base Um, I think rtx is what they have some hooks in for right now. We really prefer that to be zephyr It's open source And then we still have some of the ongoing work with the integration. So We want to make a building zephyr with tfm to be kind of seamless That means, you know doing a make versus Making zephyr creating an image going over to tfm creating an image running some scripts to combine the images correctly We don't want it to be that complicated because you know Generic user is going to come in here and that's too much work for them to understand They shouldn't have to understand that really what they should come in and say, okay Make zephyr make tfm that goes over and makes a tfm image and then package it and be done So that's really the goal that we want when we get to the end and I think That's it. So I added some links at the end Last monday PSA opened up Well, they they put their documents out public documents. They're still I think an alpha But all of the documents are available. So if you go to that site, you have to click on each one of their Each one of their documents separately to download it But they are out there. So that's good. So I would I would suggest if people are interested in this go download all the documents and take a look at it They have some great information about PSA. They also have some really nice threat models Which which are very useful When you go and you actually create a product or you decide what you want to do you really need to think about Creating a threat model to understand what pieces of the of the system you need to protect And how you're going to do it. So their threat models are great examples Um, if you want to check out the trusted firmware itself the the code, um, there's the link to that I think that's going to change. Um, it's going to be Moved somewhere else. I think under lanaro But that is still accessible today and I ran through a bunch of information. Uh, we're at the end. So I We're at the I can field some questions. I'm sure there's quite a few. Um, if you have a question We need to get the mic to you so everybody can hear the question um So first question, uh In case of single core, um the contact switch Then it's a contact switch. Yes. What is the overhead uh on v8 for that? I don't think it's very high. Um, they use some banked registers. So really it's it's I don't know. Maybe one of the arm guys has has numbers on this, but I don't think it's very high It's definitely not like doing an ipc call Okay, all right I haven't timed it and really the boards that we have aren't good candidates for for timing it anyway I've I've seen on some uh, some t implementations It could be quite high on on android phones, which leaves me, um, do see sefer Moving away from tfm and all the way to t whereas tfm a spec that is That other architectures could possibly implement so the overarching Documentation or Process that that they want people to use is psa Tfm is is merely an implementation that is psa compliant. I think that's the language that arm uses They're very happy to say if you want to implement whatever architecture something that You know does the different requirements that psa requires then you would be have a psa compliant solution for that architecture as well So I think the important part is is that It adheres to the psa Any other questions? I don't know if that's good or bad Okay, well, I guess uh, well We're finished Thank you