 Good morning, afternoon everybody. My name is Sandrine Bayeu. I work as a staff software engineer at ARM and I work on the trusted firmware A open source project. I've been working on this project for quite some years from the beginning of the creation of the project in fact. And so this is going to be the subject of this presentation. We're going to give you a technical overview of this project. So I'm co-presenting this with Joanna Fally who is the engineering manager in my team. And without further ado I'm going to hand it over to her. Thank you Sandrine. So as Sandrine said today we're presenting the trusted firmware A class project. And I'm going to be giving you a brief overview of some of our base features. And then Sandrine will take over towards the middle of the presentation to give you an update on some of our more recent features that we're either currently working on or just delivered. So as I said I'm going to give an indication of the foundational features. So what is trusted firmware A class? So TFA as it is often known for short is a reference implementation of firmware for the ARM A class processors. So A as in the application class. So this is Cortex A for client devices and Neoverse for the infrastructure device market. A lot of our work with this reference implementation requires us to work closely with a group that produce within ARM that produces software and architecture and hardware specifications. And what we try to do is provide a reference implementation that is compliant to these standards. So the project has been going approximately since 2013 so roughly seven years now. And it's a reference implementation of the ARM trust zone architecture. That has two states and as you can see in the diagram that's the normal world and the secure world. As well as the two different worlds we have these what are called ELs or exception levels that represent the levels of privileges that are available at those exception levels. And as you can see in the diagram you've got applications and the kernel hypervisor and then at the highest EL level we've got the firmware. So typically the relationship between the normal and the secure world is master slave relationship where the normal world communicates to the secure world through the SMC layer and that's the secure monitor core layer. This is a defined specification as I mentioned that ARM produces that indicates how parameters should be passed through registers and return value and it's a synchronous exception model. So for the TFA project the bits outlined with the purple line are the components that are included in the the source code of the TFA project and the goal is to provide the foundation for a trusted execution environment in the secure world. So it's an isolated execution environment it's a high level of security and this is where trusted OS is and trusted applications can normally provide services from to the normal world. So the code is designed to be reusable for different platforms and what we have is a some core code as well as a platform code that has been upstreamed from consumers of the of the repository and it's approximately 350,000 lines of code but a third of it is the core code and the other two-thirds are the various different upstream platforms of which there's about 30 coming from approximately 15, 16 plus vendors. The code is 90% C and 10% assembler code and there are many build options to support different aspects of the architecture. It is released under the BSD 3 clause so there's almost unlimited freedom to consume the code base and so it's very consumer friendly and we also take contributions under the developer certificate of origin that allows a more relaxed contribution model than having to go through any sort of legal contract to release patches and code to the repository. Since around about 2018 it's been transitioned to the trustyfirma.org organization as an open governance project as opposed to an arm-run open source project and TFA is a number of one of a number of them a firmware project that is under this umbrella. It's not the objective of this presentation to talk about all of those but I would urge people interested to go to the trustyfirma.org site and explore the other offerings that are available there. We have approximately a six month release cycle so we have a single master tree that we tag with a very lightweight process for when we do releases and we have an ongoing CI continuous integration system that helps maintain the quality patch by patches that are merged into the project. You may notice there's a gap at EL2 in the secure world level and one of the features that Sandrine will be talking about later will be this secure partition manager which is a new capability that is being provided. So if we look at the boot flow we have a number of BLs or bootloader images that are provided. So the first BL1 and BL2 are very transitional transient images that only last around for a period of time until we can get to the BL31 image which is the persistent image that you saw in the previous diagram. So BL1 is the first code executed and it's pulled from ROM and it provides a minimal level of initialization to be able to authenticate the BL2 image which is an updatable image and also hand off to that image. So the BL2 image provides some additional initialization and again it loads and authenticates the persistent firmware image the runtime resident BL31. BL31 also known as the EL3 monitor firmware has primary purposes to handle the transitions between the normal and the secure worlds and offers runtime services. There are other images that are outside the remit of the TFA project in the diagram and also shown here and these are commonly the BL32 which is the trusted OS in the secure world and also BL33 which is normally a normal world bootloader that often leads to the you know the booting of a rich OS like Linux or Android or a hypervisor. The boot flow has the capacity to have more platform specific images to be created but that isn't part of the core code that's up to the various platform providers. So trusted boot. So previous slide I talked about the boot flow but one of the big aspects of this project and it's hinted at in the name is that we need to trust the boot process and it's all about trust and there's another arm standard that architectural standard that we look to be compliant with and that is the TBFU the trusted boot firmware update and this allows the design of a more trustworthiness mechanism through something called the chain of trust for the firmware images and this is where the different images are signed with a key a cryptographically private key that is used to sign all the firmware binaries and then as you go through the the boot process that can be verified with the public key. So the images are signed with the root of trust public key the ROTPK and that is available from the BL1 for verification and that is in the ROM image that originates the boot process. Key here is to note that if any of these authentication steps actually fail we stop at that level and we fail too and we stop and refuse to boot. There's an optional cryptographic hardware option that could be used that might be more efficient than some devices for the software rather than software verification on the CPU. So multiple signing domains is a mechanism where we can have multiple roots of trusts for different images and it's a mechanism that's currently under development and it better reflects an ecosystem that's made up of multiple silicon providers ODMs, OEMs and OS these where different images might be coming from different sources and it helps to alleviate the problem of everybody having to use a common root of trust. In addition to the firmware signing sorry the firmware image signing at build time and verification at low time we can have image encryption at build time and decryption at load time. Power management is another key aspect that's architected and specified in the ARM architecture and this is the PSCI specification the power state coordination interface and here it's key that the software images must interoperate when power is being managed. So this is for core idle management dynamic condition and removal of cores secondary core boot and system shutdown and reset and TFA provides a PSCI runtime service that provides this management to the lower level ELs through the SMC calls. There is there on some devices the possibility of having a separate micro controller mic processor often referred to as the system control processor that performs and has responsibility for the power management functions. As I said this may not be present on all designs and for interfacing to this there is a system control and management interface standard specification that is used and this specifies the interface for power domain performance clock sensor and reset domains and various functions and the TFA code base provides a compliant reference implementation of a by an SCMI driver and in this particular model all power management is delegated to the SCP through that interface. Another aspect that's quite important is exception handling so the specification the SDEI the software delegation exception interface is a standard for delivering critical system events. The TFA provides a compliant reference implementation of this and again it's managed through SMC calls where you can register callbacks from the iOS and hypervisor from the upper levels of the ELs and when triggered exceptions are passed to and serviced by those the OS and hypervisor. When these events are triggered it's expected that they will preempt any critical sections and in those in the OS or hypervisor layer. It's important to note that not not shown here is a more general firmware interrupt management handling system and these these systems need to coexist. So platforms through the SDEI can make use of two levels of event priority and they can be the hardware or software generated. Examples could be hardware failures say for every corrected memory failure or they could be in the ability to do profiling say for instance so you could profile when every 100 SMC calls are being performed or have been processed or it could be for debugging. A debug UART event is another type of exception. In the current implementation of TFA we we do support platform error handling through RAST reliability availability and serviceability, routing RAST events up to the normal world to be be handled. So the ARM architecture is constantly evolving. The hardware architecture updates are generally provided yearly. They often blog about in around the September time zone time range and they are then made more formally available in the ARM ARM architectural reference manual in the following spring and these various features support the usage of the ARM V8 architecture in multiple types of markets whether they're client devices like phones and laptops. Infrastructures like servers, network switches, IoT, smart edge devices and automotive so vehicles. The TFA code base and repository involves to support these new architectural features as necessary. Features are added to the master branch as they're implemented but as you can see on this slide we actually in our six month tagging we formalize their availability. So that is a rundown of some of the base features that TFA provides and I'm now going to pass back to Sandrine to give you more ideas of some of the newer features that we're working on. Thank you Joanna. So the first feature that I'd like to talk about is the idea of making the firmware more generic. So the situation today is that whenever you compile your firmware you compile it for a specific platform and that binary only runs on this specific platform. It won't work on another one and that's because all the platform information is expressed through a number of platform header files. You can see an example of this on the right hand side where we have the ARM platform header files defining stuff like the memory map, the interrupts, some of the device settings and so on. So all this information is built into the firmware and that makes a specific binary specific to your platform and what we'd like to do is to have instead a single firmware stack that is able to run across a range of platforms. So this is not a new idea. I'm sure all of you are aware that that's how it works in the Linux kernel today. You usually compile your Linux image for a specific architecture for example ARM64 and then it runs on all ARM64 platforms provided that you have the right device tree for your platform. So we'd like to do something very similar for the trusted firmware and move all differentiating configuration options to a configuration file that the firmware would parse at boot time to self-configure itself for this specific platform. Now we realize that such a feature is not free. It does have performance overhead because obviously you need the code that will parse the configuration file. It also increases the memory footprint to include this additional code in the image and also to load the configuration file and it just adds more complexity to the firmware. So for some other devices for example highly constrained devices this is not something that might be desirable. They might still want to continue having a tailored firmware for their platforms but even for these devices we believe that it would be a good idea to use configuration files to express platform data anyway because we could have a tool that runs on the build host machine that parses this configuration file and generates the platform header file that I've shown at the beginning of this slide and that way all platform data is expressed through the same mechanism configuration files rather than having a mix of configuration file and platform header files. So right now we are using the device tree format for this configuration files and we're using the libfdt to parse them at runtime. Now we might support alternate formats in the future but for now it's the only one. So along just to give you an idea of the kind of information that we would like to move in this configuration file. So aside from the traditional hardware configuration you would typically found in a Linux kernel device tree like the CPU topology some of the devices, base addresses or settings we could express secure firmware features for example. So Joanna talked about trusted boots previously having a Boolean flag that you can just toggle in this configuration file can be quite handy when you are in development mode because it enables you to enable or disable it without recompiling your firmware. Similarly you could have the log level in this configuration file to control the verbosity of the messages printed on the UART or the location of the images that the firmware needs to load and authenticate. This configuration file could be used also to pass information from one firmware stage to the next or even to the Linux kernel or the bootloader. Examples of that would be some memory that we have probed and we want to avoid the next firmware stage to prob it all over again so we could just pass this information in the configuration file or if we reserve some secure memory region and we want to tell to the Linux kernel that it's something that you should avoid accessing because it's a secure memory that's another thing we could put in the file. The last category of options we could put is configuration of a specific firmware component. DDR training parameters is a prime example because we've seen examples of platforms that are extremely similar and they only differ on the way they need to train the DDR so if we move this information to the file again you can use the same firmware across the two platforms. I'm sure most of you were already familiar with this concept so I would just like to give a bit more details about how we've implemented that in the trusted firmware just to give a different perspective. So we've based this code on the firmware configuration framework or fconf. That's a data abstraction layer to access this configuration data so basically we have different modules as you can imagine in the trusted firmware, the power management module, the IOLayer module and some of these modules will want to consume some of the data that is inside the configuration file so the way they would do that is that they would register a callback responsible for extracting the configuration data they are interested in. So here you've got an example where we call the fconf register populator macro and we want to extract the topology information out of the hardware configuration file and that extraction is done by the fconf populate topology callback that the module has to provide. For each call to this fconf register populator macro it actually registers the callback in a specific linker sections so all the callbacks are gathered in this section. So when the trusted firmware boots the configuration data needs to be passed so every callback that has been registered in the linker section is called and each one of them will go and pass the device tree and extract the information it needs. So here we've got an example where you could have a device tree with a CPU's node and the fconf populate topology callback is responsible for passing this node. It knows the bindings of these specific nodes so it can find information it wants and then it will populate a global data structure in this case the struct hardware topology with the different information it wants to keep. Later on the different module can query the global configuration data that has been extracted at step two. One example here is by calling this fconf get property and saying I want to retrieve the topology information out of the hardware configuration information and more specifically the plat cluster count information and that's the way it will get this specific piece of information. Now I've mentioned that this feature is not necessarily interesting for highly constrained devices because of the performance and memory footprint overhead it adds but even for these platforms some of these structures stays the same because the global data structure like the strict hardware topology can still be provided by the platform layer like static data and the way the rest of the code would want to access this configuration data does not change it's still going through this fconf get property macro whether this information has been extracted from a configuration file or whether it's provided statically by the platform layer so that's why in that sense fconf is a data abstraction layer to access this data. So now the second piece of development we've been working on lately that I want to talk about is some work we've been doing to re-architect the secure world software. So first of all let's take a look at how things look like today. So here you've got a diagram of a typical software stack on the left hand side you've got the normal world where you've got your user land applications running serviced by your kernel and potentially managed by your hypervisor if you've got one and on the right hand side you've got the secure world where the trusted firmware runs. So the trusted firmware runs at EL3 which is the highest level of privilege in the system and as Joanna has already explained one of the duties of the firmware is to provide some runtime services. Some of them are secure services like secure payment secure storage and some of them are platform services like trusted boot power management or even some silicone vendor services. So these services would be typically specific to your system on chip. So that makes up for quite a lot of services in your firmware and as you can imagine it increases the code complexity and also increases the attack surface which is not good from a security point of view because remember it's running at the highest level of privilege so if you find a flow in the firmware that you can exploit you've basically you rule the system and the second issue is that it increases the fragmentation because as I as I said you've got some platform services inside it which are specific to your sock so that goes against our our desire to have a generic firmware here. Now it's still looking at how the architecture looks today if you can have a trusted OS running in the secure world to manage some trusted applications and typically when you've got this architecture the trusted OS takes over all the secure services like secure payment secure storage and so what's left in terms of services in the trusted firmware is only the platform services so it makes the code bloat issue a bit less important because your firmware is a bit smaller but it doesn't solve all issues it even brings new ones so the first one is that the trusted firmware is typically provided by a different vendor than the trusted OS and prior to ARMv8.4 there was no hardware isolation provided between secure EL1 and EL3 so in other words between the trusted OS and the trusted firmware which means that for example the trusted OS can see just as much memory as the trusted firmware it can access any address there's no way to have for example some memory that would be specifically mapped for EL3 and forbidden to the trusted OS so that means that the trusted OS vendor and the trusted firmware provider have to trust each other basically which is not always possible the second issue is that whenever you start using a specific trusted OS you also need some companion components all over the software stack so these are the green boxes in this diagram you can see that you need a specific driver in your kernel in your normal world kernel to talk to this specific trusted OS same for your hypervisor if you've got one and you also need some code in the trusted firmware that is responsible for recognizing and delegating the secure monitor calls that are targeting this specific trusted OS so the model we would like to move to instead is to move all services up the exception levels so to take them out of the trusted firmware and move them for example at secure EL0 that way the firmware is a lot more smaller so the attack surface is reduced the complexity of the code is reduced as well and that in turns makes it easier to audit and certify the firmware if you need to also the only remaining services that you've got in your firmware are standard services such as the trusted boot, the power management or the secure monitor called hender because all the remaining platform specific data are expressed through configuration files if we use the the fcon framework I've been talking about just before so that makes for a truly generic trusted firmware that can run across any platform now what I've just explained on the previous slide solved the code bloat issue the other issue if you remember was the fact that the trusted OS and the firmware had there is no isolation between them so to solve this issue we can leverage the mv8.4 extensions and more specifically the secure virtualization so in mv8.4 we now have virtualization in the secure world as Joanna mentioned in one of the previous slides there's now a new exception model sorry a new exception level which is secure el2 and that gives us an opportunity to put some firmware code in this exception level to isolate el3 from secure el1 the other piece of the puzzle is also to standardize the interfaces the communication interface between the different components in the stack if you remember on the previous slide I've explained that when you've got a specific trusted OS you need specific drivers to talk to this trusted OS that's because each trusted OS does it its own way but if we standardize the communication interface then you just need a driver that implements this specification in a standard way and and and the program is solved so that's achieved through an ARM specification called PSA FFA which I will talk more in a second like that you can see in the blue boxes at the different software boxes boundaries so that way we can have generate code running both in el3 and secure el2 now I would like to just give a bit more details about some of the building blocks in this architecture so on the left hand side you've got a diagram that is basically the same as on the previous slide so first building block is on the on the top the the trusted OS with with its trusted applications and the platform services so these are two what we call secure partitions so a secure partition is a software sandbox that runs in the secure world and it's a sandbox because it's got its own execution context and its own address space isolated from other secure partitions so that makes it possible if you've got several providers for your secure partitions they don't need to trust each other because they know that there will be no unintended inter communication between different secure partitions the second building block here is these blue blocks where you've got the SPM or secure partition manager so that's part of the secure el2 firmware and its responsibility is to initialize all the secure partitions at boot time and to enable the communication between the service requesters and the providers and manage their requests at runtime one other key role of the SPM is to enforce the principle of least privilege because when the SPM sets up the execution context and the address space of a secure partition it will just give it the minimum that it needs to see so it will it will set up the translation tables of this specific secure partition such that the address space the secure partition sees is just what it needs not more same for the physical interrupts they are directly managed by the secure el2 firmware and they won't be forwarded to a secure partition if this partition is not supposed to know about this specific interrupt so in terms of implementation we currently have in the trusted firmware a project an initial version of an SPM dispatcher that is compliant to the PSA FFA specification i talked about before so the PSA FFA stands for platform security architecture firmware framework for a class processor the PSA is actually a class range of documents and so FFA is just one of them so it's a standard set of interfaces between secure partitions and the secure partition manager on one side and also between the secure partitions and the normal world and going back to the status the implementation we we've got an initial secure el2 firmware that is based on the Hafnium project which you might have heard about it used to be a google project but it's been migrated into trustedfirmware.org this year to serve as the reference secure el2 SPM of choice so these were two quite recent pieces of development we've been working on there are more than than than just these two so if you want to find more about the projects here are some useful links so we've got a public mailing list for technical discussion we are also organizing a call every other week with the community that anyone can join to discuss anything here is a link also to browse the source code and to the gary server we use for code reviews we've also got quite extensive documentation of the project that is hosted on read.docs and we've got a test suite that is also open source to exercise the trusted firmware and finally if you want to find that more about the trustedfirmware.org initiative in general not specifically for tfa here is where to find the monthly project status update in the board meeting minutes so thanks a lot for attending and i guess we are ready to take any questions then hello i believe that we have around about four questions in the list at the moment and i can if i take them from the top i think that might be the best best approach so the first question is how well are the silicon vendors upstream in the soc support well as mentioned in the first slide there are there's a there's approximately 30 plus platforms now upstreamed from about 16 plus vendors it you know when the project started of course you know the the number of upstream platforms was minimal but as time has gone by since 2013 you know we get you know a number of new platforms for every six month release that we we talked about and well what we do is we provide or we nominate from from the people upstream and a platform owner and we work with that person who's responsible for upstream in their their changes a lot of the discussion goes on in gerrit where there's you know patch reviews but we also have a quite a busy mailing list where folks talk about you know their ideas and issues that they're having with the platforms and as also mentioned by sandrine in the last slide there's a bi-weekly tech forum and this is a live call that we host where we discuss the any issues as well as presenting new ideas and and so forth you know that's going on in the project so i i would think you know you you ask how well i think i think it is going reasonably well with the platforms so the next question was what is the actual motivation for the generic firmware idea so the idea is really that some platforms have very few differences actually one of the examples that was explained in the slides were like you've got pretty much the same hardware but it's just different ways to train your ddr with different settings so in this case it's it's not always very convenient to have two builds of the of the firmware with just the settings that change that you have to deploy on on both platforms instead it's just more convenient and easier to move that to some configuration file that is read and you get the same binary and you just have to to change the configuration file depending on the platform that you want to deploy the firmware on so that that's really the idea hopefully this answers the question the next one was where is the configuration data stored and how do you validate its integrity does it need to be signed so the configuration data is stored along the firmware binaries usually in some kind of flash or non-volatile memory secure storage or not necessarily secure storage in fact because yes it is signed so it could be in non-secure flashed and if you enable trusted boot which is an optional feature then all the images in the bootflow are signed and verified at at runtime including the configuration data file so question number five was what is the advantage of power management in secure world so the idea of putting psci in the trusted firmware at EL3 in the secure world is that um usually power management is driven by the um rich os i mean the the normal world os like linux um and um but you might also have a trusted os running on your platform and if if the if linux decides that it wants to shut down some cpu um well the trusted os might need to be notified of that in order to do some context saving before uh the cpu's gets turned off and so um this coordination task is taken care by the firmware so linux will ask please uh turn off the cpu and then the trusted firmware make sure that any anyone in the secure world that needs to be aware of that before that happens is notified so that's really um a coordination role so question six is are there guidelines how to coordinate access to components that need to be accessed by tfa and linux um i don't know what you think sandrine but i i think of course we have a number of them standards that um that we we work to and we implement these apis they're also implemented or a number of them are implemented by the the kernel as well uh well typically i would expect that a device is um either owned by the kernel or by tfa but there is no i mean if there is if both of them need to um coordinate somehow because they manage part of a device only um then they would need uh yeah some some kind of communication mechanism um but um i'm not aware of any standard from arm or anything like that specifically for some some devices so i guess there is no there is no as far as i know so there there the next question is thanks for the presentation it was really informative will the slides be posted i believe they will be um the next one is is there anything about trusted firmware that uh can be integrated into ids through plugins um so i'm not i'm not sure i understand the question i'm assuming this means um can you like uh use eclipse or something like that when you develop trusted firmware code uh that can automatically build the code or something like that um what's your take on this one uh jenna how do you understand the question yeah i'm not sure if there's any special tfa support for ids you know we don't develop any particular plugins um but we you know people can use ids in their development um of tfa and a number of folks do um but there's not much i think i mean that that that is for a that's part of the project at least yeah yeah um and the last question i believe is uh is el2 execution mandatory to use spm um so spm i mean spm will really uh reach its full power when you're using secure el2 uh that's for sure uh now we realize that uh some platforms uh i mean before i'm v8.4 they don't have secure el2 and they might still want uh to use spm uh so that is possible there is a migration pass but it's really not um the main use case we are targeting so there will be limitations um but it's not strictly mandatory uh but but if you if you want the the full power of it it is it is recommended yes so there is the opti option sandrine isn't there where the people are using the opti trusted environment as a as a an spm solution that talks all the appropriate apis but as you say that's a migration path to um um you know the the real secure el2 whereas um um the opti of course is at el1 yeah yes and uh as we mentioned opti so if you're not aware of that i mean that's a trusted OS implementation that is a open source and available through trusted firmware.org and i think we've covered all questions and run it at time i think yes uh so if you've got any more questions uh i encourage you to join us on the slack channel so we've been advised to use the number two uh on the track mbd linux so we'll stay uh for some time if you go if you've got any other questions thanks a lot everyone and for for attending and for the questions thank you