 My presentation is about improving the security of computing services. It's mostly trench boot, so open-source dynamic root-of-trust framework, and it's short update about status of the development for AMD and after me, Daniel Kipel will present about interstaff. So my name is Pat Krull. I'm founder and a better system consultant at Triumph Dep, Polish consulting company. We're mostly doing open-source firmware, core boot. We're also doing, we are UFI adopters, we are Yocto participants, so we are also engaging in those projects. So just to quickly start, what's the problem? So I assume everyone knows what static root-of-trust for measurement is and what dynamic root-of-trust for measurement is. But just to tell what's the problem with static root-of-trust and why we need dynamic root-of-trust. So first of all, static root-of-trust, to establish trust state on the platform, we need to boot the platform. So when platforms running quite a time, we cannot say what really the state of trust for this platform is and to establish it, we should just reboot that. Of course, this is not possible in various situations. We cannot expect from users that they will reboot the laptop every time they want to do something sensitive. We cannot expect that amazing servers will reboot to establish trust. So that's why we need dynamic root-of-trust. Also, if we have something like LUX plus TPMs or encrypted file system, which relies on some secrets, on unsealing secret based on PCR values, we have to have some mechanics that after firmware update will provide new PCR values to TPM. Doing that in a secure way, it's hard and challenging. So the question is when we should do that, if we don't have dynamic root-of-trust for measurement. Also, if anyone is familiar with vendor-specific static root-of-trust implementations like Secure Boot or Boot Guard or AMD hardware validated boot or NXP equivalent, they know that to even provision platform with that feature, you need special tools. It's not like we have open tools to provision everything and boot guard working with those special agreements with Intel or any other companies that are named here. So that's also a challenge of static root-of-trust. So we also try it many of these tools and have to say this is very hard. Also, well-established BIOS vendors can have good agreements that can use that tools without problems. So having dynamic root-of-trust, we don't need static root-of-trust and can't re-establish trust in the platform. Other thing is let's say some device coming to us from offshore company and we just want to make sure that what we're flashing, even if we're flashing fully BIOS, it's really what we want. With static root-of-trust, we cannot do that because we don't trust what came to us from offshore vendor. So we need some mechanics that can re-establish trust in the platform. This is what dynamic root-of-trust should solve. Of course, there are some minor problems with that, but maybe this is a discussion for the beer tonight. So as I said, we want to solve this problem of re-establishing root-of-trust in a dynamical way. We want to do that at any point of time of platform life. This should be used also very useful in cloud environment when uptime is critical. When we have bare metal cloud environment, of course, the vendor provides the service for someone, then this customer use that, then reveals that platform, and we want to pass that to another customer. But we want to make sure that the hardware was not compromised. So we need some mechanics that can re-establish trust in that bare metal cloud component that we passed to another customer. We also want some remote attestation. Of course, as I said, secure the flashing of the firmware would be also cool. This is also related with what Thierry said on the previous lecture that when the hardware coming to you, they re-own the platform. So in some cases, we would like to reflash firmware in secure way and make sure that let's say only firmware signed by us can be flashed in the future. How many of you saw that picture? One, two, a couple, that's good. So this is screened from the trust and computing group specification about the dynamic route of trust measurement. It just showed the life of dynamic route of trust. So let's say we have some platform, we put the platform, we have to do for some implementations of dynamic route of trust, we have to do some configuration, then we have so-called gap. This is, to be honest, our firmware. We don't trust our firmware that came with the platform from somewhere. Even if there is inside static route of trust measurement, we just expect it to prepare environment for running dynamic launch event, which is our hardware feature that gives us ability to re-establish the trust in the platform. So then when we run this dynamic launch, we should have measured environment and we should make sure that whatever we're running right now was correctly measured in the TPM or whatever security module we have. From that point, everything we're running, we can build chain of trust, despite what was before. Yeah. So the goal of Trenchwood Project is to implement open-source implementation, because so far, I don't know if you're familiar with Tboot. Tboot is implementation of DRTM based for inter-platforms. But the problem is that Tboot does not support, for example, AMD and probably other vendors. This is not like the Agenda. So the plan is to create a project or it's already existing and evolving that will support DRTM just out of the box with any distribution across all components that have to be supported, which is Bootloader, Linux kernel, and probably maybe in some cases, firmware. Okay. So I assume that all the basics of Trenchwood can be understood by the presentation that I gave in the past on open-source firmware conference and platform security summit. So if this is new for you, it would be great to look into those presentation. Okay. So how does state look today? I'm right now, I'm starting to speak mostly from AMD point of view, because this implementation is divided, Oracle and Daniel are doing more Intel stuff, Intel TXT, and I'm doing more AMD stuff. So SKE-NIT. And in our case, we're using PC Engine's platform, which is a core boot-based platform. Okay, I'm a small router. We have SRTM implemented with core boot. In this case, we're running some payload, which is still in spy flash. This payload is GRUB. GRUB implements all the things that are necessary for preparing environment for running SKE-NIT, which is a special hardware command that which is equivalent to this dynamic launch event that I showed on previous slide. And then we execute special small binary, which is called a landing zone. And this landing zone have all the primitives to establish trust on this platform. Then this landing zone calls Linux and some small Intel MFS. Right now we're using Qroot. And then from that point, we can Kexec everything what we want. I don't know if you heard about Kexec in Windows on last open source firmware conference. I know that some people did that with VMware. Definitely kernel is possible. We did that also with Zen. So this is how things look like. So in short, just on the bottom, you see how this match to the previous slide. What components in the colors is what from previous slide. Okay, so what's involved to make it happen? So definitely we need hardware. And if we compare, so we have Intel and AMD hardware capable of doing that. We need some firmware. So we mostly on Coreboot. We're doing mostly in Coreboot. But definitely this would be possible with UFI. And I know that Intel TXT will probably start with UFI. Then of course bootloader right now only grab. And yeah, so I have to move on. So I have more information here about platform. Maybe this is not the most important thing. What is very important for AMD is that AMD implementation can be fully open source. So landing zone is already on GitHub. You can look into the code, how it looks like. There is no dependency, no closed source dependency. In case of Intel, it would be very hard because ACM BIOS and ACM INIT, which right now are closed and there are no plans to open that. And our plans, what we have to do is like, we definitely need some more protection like DMA protection for landing zone. We're working on that. Yeah, so right now everything's working. You can test that by simply building Coreboot binary plus adding some root file system. And you should be able to check that PCR 17 and 18 were populated with correct values of measurement. In case of bootloader, it's like 1,700 lines change to grab. We want to upstream that. We're waiting for RFC for Intel TXT just to make sure that everything will be aligned and have common design. But fork of grab is on our GitHub and you can also take it and try to use that. We change a bunch of things. I will not dive into details because it's more about implementation, but our goal is to merge everything into the upstream project. Landing zone, it's like 2,000 lines of code. Right now it lives on Trenchboot repository. So this is definitely related only with AMD. ACM as in it is the equivalent on Intel site. So this is very small, like 432 bits. It's like 12 kilo. And there were many improvements since last presentation. And we would like to thank Andrew Cooper and Zenproject for supporting us in improving. We added shot of 56 measurements. So everything looks correct right now. And after implementing DMA protection, we should be good to go and provide that to distributions. Okay, this is about DMA. And there is also additional recently, the Matthew Garrett provided post that there may be other ways to mitigate DMA attacks that may happen at the point of dynamic launch event. In case of Linux, I believe like Daniel will talk a little bit more about that. But what we were able to do was to use Linux and URUT as a DLME, which K-exact Zen in which we run virtual firewall, which was PF Sense in this case. And there are many patches that coming to kernel to support that. What we want to do also is our reproducible builds. Interesting thing, URUT is written in Go. So it's supposed to support reproducible builds by default but only in your build in the same path. So it's not exactly, if anyone will build in different path, the shawsome will be different. So this is not what we want. Okay, so that's all. It's like marketing stuff, 3M depth. Okay, thank you Peter for the introduction into the DRTM. My presentation will focus on Intel TXT implementation, both first for Grapp and for kernel. My name is Daniel Kipper. I work for Accor and I am also a Grapp upstream maintainer. I prepared this presentation together with my colleagues, Rosflipson, who is working on the kernel side and Daniel Smith, which coordinates the Trenchbook project in general. So some legal stuff at the beginning and the Grapp thing. It was decided to choose the Grapp because it is one of the most common bootloaders in currently existing systems. So we are focusing on it now. And immediately at the beginning of Intel TXT implementation, we realized that we have to change the boot Linux boot protocol. And after quite long discussion with x86 maintenance, we hammered out something which is called kernel infrastructure. It is an addition which allows you to convey some information from the kernel to the bootloader. Currently, this infrastructure is Linux kernel for 5.5 and we will build all solution on top of that. We also need to add some commands which are needed to initialize Intel TXT or AMD SK init. One is, one command will tell the Grapp that we have to switch to the RTM, I think more or less. Another thing is command which will load in case of Intel TXT the ACM module into the RAM and in case of AMD SK init LZ. I think that this part can be automated and we at some point drop this load module command. Also we need to add something which is called relocator. This is a small piece of code which move the OS image in the final resting place in the memory. As Piot told, currently both implementations for AMD and TXT are done separately, but we are going to merge them. I'm going to post that Intel TXT RFC. I think that at the turn of February and March, I have to admit that I was able to run ACM just before the forced them. So I hope that are pretty close to have Intel TXT environment running at the beginning of February. And AMD SK init will be revised on my Intel TXT developments because we feel that much of code will be common for AMD and Intel TXT. So let's move on to Intel implementation. At the beginning we have something which is called, at the beginning of the kernel, we have something which is called SLSTAP. We can compare this piece of code to something which is called EFISTAP. And this thing is split in something which is called SLSTAP entry. It lives in the text section because this section is tightly organized. We have to do some minimal things and jump almost immediately to SLSTAP's function which lives in the text section. And SLSTAP thing is responsible for all BSP CPU initialization. So it means that it loads GDT checks and prepares TXT heap or enables some interrupts, wakes a piece and pack them in special place. I will discuss this thing a bit later. And also this piece of code restores Amteria RAS and MSS which were clobbered during Intel TXT startup phase. Also there is something which is SLMINE, this part of code before executing any code or accessing any data does all measurements on that data. So this means, for example, that boot params or commands or arguments which are passed to the kernel are measured. Also, if you have intramfs present as a separate module, this intramfs image will be measured. Also this part of code validates and loads correct values to Amteria RAS. And after that we jump to the kernel proper and initialization of Intel TXT happens in something which is called SLSTAP. This part of code lives in setup C and is called from setup arch. And the responsibility of this part of code performs following tasks. So it checks that we run in secure launch in secure launch. Checks the platform is properly initialized, verify VTG PMRs also reserve some regions like TXT heap, TXT registers in E8 to NMAP, validates E8 to NMAP against MDR, passed from TXT to the MLE, and also pass ACPE IDMR prepared by TXT to IOMU driver. Also, as I told earlier, we have difficulties with starting APs in SMX mode because we cannot do that in a normal way. So after very long discussion with different people, Ross who is working on that decided that the best methods to start APs is park them in special place. They are simply stopped in health state. We also consider a busy loop but I think that it is better to just stop them in a health state, as I said. And then if you go in the SMP bring up code, these APs get NMI API from BSP and later the initialization happens as normal. Initialization happens as normal. There is also Kexec part. This part is needed to switch from MLE to OS kernel. This functionality also will be used if we would like to initialize DRTM. Currently we are focusing on stopping SMX mode. So during the execution of Kexec quite late when everything in the platform, almost everything in the platform is disabled, all APs are stopped. This part of code just does some play with TXT register and call as exit. And this causes that BSP leaves SMX mode and later OS kernel is started. If we would like to use the new OS. In case of establishing new DRTM we have to re-initialize platform and use a Kexec center. We also need some, we also need in MLE some access to the TPM log. This is needed because the security framework which usually runs in user space have to get some information from the TPM event log. So this is done by exposing the log via note in the security FS. Currently we had to review for second version internally as far as I can tell, Ross and Daniel currently are working on new third version. I hope that it will be published soon, maybe together with the grab code because both pieces have to be synchronized because there is a boot protocol and this boot protocol have to be properly defined. That is why I think merging probably will happen in that way that first of all the kernel will be merged and then after that if the boot protocol is established then the grab code will be merged. So that's it I think, questions. Also for my part and for Peter part. Yeah, I know we run through that very, very fast. Yeah, sorry about that. You don't have background on the trench boot but if you have like any concerns that jump up directly just let us know, maybe we can clarify that now. Yeah. So guys, how are you plugging into kind of remote and a station infrastructure? I believe this is like way in the future but I believe this would be, it's already used in some way by some commercial companies. I believe Microsoft already doing that. So I believe you will re-establish kind of secure environment on demand and from that you will start, of course, using TPM, behind the station, send the information about the measurements and then if everything is fine then at the station. This security environment can live in both places. First in MLE and second can live also in the OS kernel which is started by OS MLE. We are internally, we are looking at different solutions. Sadly, I'm not able to tell much about that but we are also considering open source solutions which are currently quite mature. There are so many remote attestation servers and that. Yeah, yeah. So I don't know what would be work with that but I know IETF works on some standardization and like probably we are closer to that approach. I'm sorry, I missed the point. What is the reason of putting a grab into the CPI? I'm not sure that I understand the question. CPI? It's fine. Sorry, into deflection. It's like it just simplifies our development and it doesn't have to be like that. It can be on storage. It does not. What's the purpose of placing grab in CPI? It just in our case simplifies development but it doesn't matter where it is because we measure grab, if you want SRTN part then we measure grab before executing it. So that's first thing and second thing even if we don't care about SRTN, grab executes a DRTN flow and from that point we establish the trust. So we, yeah. When you see that grab is measured, means that each model is measured on the image? In our case in spy flash, you're not adding anything to a spy flash so you measure the whole payload. So the whole grab and you cannot like intercept and add load modules at that point. In case of storing that on storage, it's like different case and like we didn't kind of thought about how this would be. This would be not like. Yeah, I know. It is much easier to measure a whole image of the grab. Usually if you would like to run the grab in a secure environment usually it is done that you have a whole image which contains all modules. For example, if you run secure boot whole image which is signed by XR409 certificate, contains all modules. Currently if you use grab upstream, it is possible to measure every module and every command which is executed by grab. It is done by something which is called verifiers framework and this framework went into the grab 2018 as I remember correctly. So you have two choices, but in case of Peter solution, it was much easier to build whole image which contains everything and this way you don't need to do additional measurement from the grab. And what happens if this is configured? Excuse me, what happens where what? It's configuration for. Yeah, so in this case, this was just a router platform. So it's everything is always the same. So you don't have to, you don't change in configuration file. And if you need to upgrade the kernel, for instance? Yeah, so what you upgrade in the kernel and you should like, you just replace the kernel. Yeah, if the parameters change, then yes. So I assume in case of if you have SRTM, then you should care about how, you know, I told about the SRTM problems. So you should care how to update your flash image with new configuration and with new components. But as I said, this is a deeply embedded platform and we should not do that like often, I believe. Yeah, so. Because it always takes a lot of time. Yeah, okay. So we can take that for a discussion. This is just the, yeah, this is just the development kind of setup and just to prove that the dynamic root of trust part work. We know that static root of trust is problematic. Sorry about that. We are out of time. Thank you. Thank you.