 Okay, so we would like to introduce you today into the theory of trust. We also discuss the Tangebook project. And let's start. My name is Daniel Kuiper and I work for Oracle. I am software developer and graph maintainer and I will be doing this presentation together with. My name is Daniel Smith. I am the Chief Technologist for After Solutions. Okay. And so today Daniel and I will be presenting on Trench Boot. So just a quick agenda. I'm gonna give an introductory to integrity and trust. Daniel will cover dynamic launch. I'll cover Trench Boot and then Daniel will talk about the upstream work that we're doing and then we'll do a Q&A session after that. Oh, higher. There we go. All right. Sorry. All right. So integrity and trust. So Trench Boot is specifically interested in the trustworthiness of booting. So as a result, the frequent question we get is why is secure boot not enough? To answer that question, what we're gonna do today is go over a common understanding of what trust is and then using those trust constructs, break down secure boot and dynamic launch and discuss that. So trust. Trust is a human social concept. Basically anytime we want something to act on our behalf, we entrust it, we give it trust. This is the same thing with computer systems. When we want the computer to do something on our behalf, we give it our information. We're trusting it to do the right thing with that information. So when we look at this trust, we need to find something that is the core of that. That's our root of trust and the root of trust we need to be able to understand why we can trust it and that is where we come into something that's called strength and mechanism. So the meanings of trust is a very good paper written back in the 90s. They went through just the human concept of trust across all areas. They specifically focused on an area called what they call system trust. This is a mechanical systems or computational system which is what we're concerned with here. One of the key things they said there is that in order to believe or have trust in your system trust is that you need impersonal structures that enable you to know that the action you're asking that to do on your behalf does it correctly. These impersonal structures, there's two of them that you can have. You can have structural assurances and you can have situational normality. We're interested in structural assurances and specifically for a root of trust, we want ones that have high degree of strength to know that we can believe in that root of trust. So what is a root of trust? So according to the TCG they just find it as a component that we expect or it must always behave a certain way because if it misbehaves we have no way of detecting that. So what does that mean in terms of strength of mechanism? So from a strength of mechanism we are worried about and this term comes from mechanics. You worry about whether or not under stress the mechanism you're relying upon will fail or succeed. So in this case we are worried about whether or not our root of trust will misbehave and the best way we can do that in computational systems is trying to drive this root of trust to be immutable. Anytime you induce immutability that is the means by which somebody can create a stress that will cause it to fell on you. So once we have a root of trust we now can rely on that root of trust to make evaluations of other components within the system and when it meets the right criteria we can then impart that same trust to that component. That is a transitive trust, what the TCG refers to as a transitive trust. You can repeat that on and on recursively and that gives you a chain of trust and that terminology of a chain of trust rooted or anchored in a root of trust is a very good analogy because in real life if you have an anchor with a chain if the anchor is in something in a soft foundation a little stress will cause it to release. We want these anchors to be rooted hard and then when your trust chains build up every time you do your transitive trust you're inducing immutability into your trust chain. That means you have create a risk that your chain can fell on you. So at the end we want to be able to build these root of trust with these shorter chains that we can then give statements about the integrity of the system. So integrity, there's really two kinds of integrity we need to be worrying about. There's our low time integrity and our run time integrity and we need the root of trust to be able to make assertions about these. The interesting thing is that there's a subtle difference, subtly about the low time versus run time. Everybody knows that secure boot is a boot time, a low time one. Dynamic launch from TCG typically is a low time but you can actually use it as a run time if you want which we'll discuss later. And then IMA, most people think of IMA as more of a run time but it's really low time. It's measuring what was loaded at the process execution. At no time does it actually inspect the process while it's running. That's where your run time integrity will come into where you wanna be able to establish and re-establish the integrity of a process as it's running so that way you can continue to have trust in what you have running. And typically the two you see in those are their kernel integrity monitoring and process integrity monitoring. So now that we've built up a root of trust, how we can expand that root of trust to components, use those to give you integrity. I'm gonna let Daniel touch on dynamic launch. Thank you Daniel for this free or thick introduction. I would like to look a bit closer to the dynamic launch. First of all, terminology, this is quite important here because it is very conflated. And here in this table we have quite nice comparison of different terminologies used in different specification. The most important one which discusses the generic idea of the dynamic launch is the specification prepared by TCG and it discusses the generic idea itself. The Intel specification and AMD specification focus on vendor implementation of the dynamic launch. The problem here is that all three documentation, as you can see, use different terms for the same thing. So if you read it, you can feel confused. This is normal, don't worry. And I'm really surprised why did it happen because in the TCG committee, AMD and Intel participated. So I'm not sure why they invented new terms for the same things. Good example is dynamic launch. As you can see, in TCG documentation it is simply called dynamic launch in Intel TXT. Sorry, it is called late launch. And in AMD, it is called secure startup. The same thing is for DL event. You can see this is called as enter or SK in it and so on and so on. There are also some terms which doesn't have relevant terms in the vendor specification like DCRTM. In general, in this presentation we will be using terminology proposed by TCG, but if we are referring to specific implementation of dynamic launch, then we'll be using terminology of a given vendor. So let's compare UFI, Secure Boot Trust and Dynamic Launch Trust. So if you start the machine, you get machine started and all firmware is taken from the flash. And initially, the Sec phase in the UFI is executed which does basic initialization of the platform and the control is passed from the Sec PEI. And then PEI does measurement among others. And as you can see, the CRTM is not measured until during the PEI. So Sec and PEI phases must be trusted and CRTM is of Sec and PEI. So these are self-referential. And the trust relies on boot flash and the TPM to protect the measurements. And the DXC phases enforces UFI Secure Boot Verification. So we have three kinds of root of trust here. The flash and TPM forms something which is called root of trust for storage. We have a root of trust for Merge and Merge which is built from a second PEI and root of trust for verification which is formed from Sec, PEI and driver execution environment. The situation looks completely different in case of dynamic launch because here we mostly depend on the hardware. How it works? At first we have something which is called DC preamble. It can be a part of bootloader or it can be part or currently running OS. And DCRTM is taken initially by the CPU and the result is stored in the TPM. In the case of Intel, there's also additional method of DCE. Just Intel CPU just verifies the signatures of the DCE. And after that, the control is passed to DCE and DCE also measures the DLME and put the results in the 2 TPM. Let's look into today how the dynamic launch work. So initially the CPU obtains locality number four and it clears the TPM, DRTM, PCRs. All CPUs are, all CPU interrupts are disabled and the CPU protects the DCE from DMA access. And AMD and Intel use different technologies to do that. Intel uses something which is called cache resum. AMD uses something which is called device exclusion vector. Then after that DCE is measured by the CPU and the result is stored in PCR 17 before the execution. And here also there is a difference between Intel AMD implementation. Intel provides ACM for every platform and every ACM is signed by Intel. In case of AMD, the owner have to provide the DCE but you are not able to verify the signature. There's no such mechanism to verify that the signature of the DCE. After that the DCE answers the DLME is the DMA protected measures and then executes it. So as you can see, in case of dynamic launch, sorry, the result is very high integrity accession of the DLME. In this case, in case of dynamic launch, as you can see, the firmware is removed from the TCB except SMI handler. So root of trust is mostly mounted in the hardware and a firmware which is usually buggy is removed from the picture. And at this point I would like to hand over to Daniel. All right, thank you. All right, so TrenchBrew, the project itself. So TrenchBrew originated from an idea I had back in 2014 when I was implementing a Ford SEAL capability and to OpenXT to be able to Ford SEAL the platform on an update. In OpenXT we use T-Boot to launch the Zen environment. In order to accomplish the Ford SEAL we needed to be able to get to certain bits of information from the measured launch in TXD terms in the dynamic launch. And in the way that T-Boot was constructed in conjunction with Zen made some things very difficult. We weren't able to get to the TPM event log. That is actually, it's housed inside the ACM's heap space and that's actually blocked out of the memory map. So Zen will not allow you to access it. Boot services is still the day. There's a conflict on who should be terminating boot services. If you follow the specification, the TCG's dynamic launch specification, boot services is supposed to be terminated before you do the dynamic launch. Right now the day, T-Boot does it inside of it before it hands over to the target system. And in our case for this situation for OpenXT or I'm sorry, Zen likes to have access to boot services as well. So we have this conflict here. T-Boot can only measure what was loaded into memory with it at the time that it was started. Only the multi-boot modules. There's nothing else that it has, the knowledge of how to do or even considered. And it only had one action, attestation action. It basically can do a policy enforcement on a pre-different term in PCR manifest. It had, and that's the best you can get out of it. And then it only works for TXT. There was an attempt to consider putting AMD support in it and they turned it down. So we need to be able to, specifically on OpenXT, we needed to be able to support both AMD and Intel. So the motivation continues. So because doing this is very important, we need to make sure that we do this correctly. We need to take the time and make sure that we have a nice clean way that we've launched the platform that we make these strong assertions from. So the project isn't meant to focus on solving this problem for everybody. And then in the past dynamic launches have been used just for the initial boot phase. And the fact is that dynamic launch can be ran multiple times through the entire life cycle of the CPU. All right, sorry, of a power-on, power-off sequence. So it's an opportunity to establish the current integrity of the platform at any time, if you want, so chose to do so. And on top of it, in the last four years now, four or five years now, launch integrity ecosystem has gotten extremely rich. There's numerous routes of trust, the routes of trust have evolved in terms of measurement. Secure co-process have shown up, spy interposers are in place now, you've got hybrid solutions starting to come out. And then on top of it you have vendors adopting these capabilities into their products. So we want the open-source system, open-source ecosystem to have these things as well. So trench boot is a cross-community integration project. There is not one thing that is trench boot. We're trying to bring these capabilities to all of the open-source projects that are involved in this. One of the questions I've gotten is, where did I get the name? So when I was working through all of this, starting back in 2014 and looking at all the launch integrity system and the hardware and everything else, it's a muddy mess. And just trying to find a way to unify all of that in a way that all open-source projects could use is just, I joked at one point that it's like, I got a strap on a pair of boots to wade my way through this so that several other people have gotten stuck in. So at the end, the purpose is to develop a common unified approach to building trust into the platform during the launch phase of the platform. And then work with the open-source community to the various projects to get this unified approach adopted by all of them. So that way, you wind up with this ecosystem that any open-source kernel and potentially proprietary kernels could use this to launch themselves if they wanted to. So this brings us to the first capability we've been working on, which is what we're calling Secure Launch for Linux. So Secure Launch for Linux is the attempt to bring the, to enable the Linux kernel to be dynamically launched by both AMD and Intel. Specifically, the focus is on a first launch scenario, which is what everybody is very familiar with. You're using the dynamic launch as part of your boot cycle to establish the initial integrity of the platform. But you can actually, we're looking at runtime integrity as well, runtime launches. So that way you can actually use this to launch your kernel upgrade through a Kexac. You could launch an integrity kernel that could set there in dynamically inspect your system. Or if during a shutdown, you wanna make sure you wanna establish the integrity of your platform before you persist everything to disk, such as an embed environments, this is a chance for you to do that. So the, compare that with the existing ecosystem of dynamic launch. Like I said, there's been numerous attempts to bring dynamic launch into the open source community. A lot of these, or actually all of these have been focused purely on the first launch use case. The Intel based ones are actually exo kernels because they try to persist themselves for the entire runtime of the system and in an exo kernel fashion, they hook the sleep states to handle dealing with the fact that your trusted kernel went into a sleep state. From my perspective, that's not the appropriate approach, but we can talk about that later. And then they have a limited or no attestation capability built into them at all. So the first use, okay, first launch use case, standard use case, everybody knows this. The difference that we're doing with trench boot is we're going to expand on it a little bit. So we're going to properly terminate boot services by the boot loader and then handle the EBS handoff using Linux's existing EFI capabilities to launch itself after exit boot services. Google has this amazing project called Uroot in which they're building these tiny and net RDS for variety of solutions for embedded boot loaders and those. So it was a good means for us to build a flexible way of doing measurements and attestations during this launch phase. The current focus right now is to be able to manage your block devices, files and system information like DMI and then to be able to take those measurements and do attestations and then establish the integrity of your platform before you allowed your target system to start running. And then we will be using the K exec interface to do the launches. When the secure launch phase is completing, we cap the PCRs on all platforms. That's a means by which we can say we're done. Intel provides us the extra capability that I wish AMD had which is the S exit instruction which allows us to basically close off access to the RTM PCRs. So that way those PCRs can no longer be extended after we're completed. And that closes up the first use case. So to give a basic walkthrough of it, right now Grubb will be able to take measurements if you so choose to. It's optional of everything it's about to load into memory to start the late launch or the dynamic logs, excuse me. It will load either the secure loader or the ACM depending on whether you're on AMD or Intel. It'll load a Linux kernel that is capable of handling the dynamic launch, the secure launch capability. And it will then call the respective event, late launch or dynamic launch event. At which point the ACM will hand out do its business. That's proprietary to Intel. It will hand off directly to the setup header or the setup code inside the kernel. And the secure loader, we have a project where we're building one and make it which is gonna be, it is open for AMD, which will basically set up the environment and transition into the setup code for the Linux kernel. Inside the setup header, we are, Daniel will cover this a little more detail. We'll take the measurements of what's necessary within the kernel. So we'll, right now we're, when the piggy has been expanded into the VM Linux, we take that measurement, we measure the INIT RD. So that way we have at least those two measurements of the things that we're gonna give execution to before we turn them over. Once you get into the INIT RD, it can then take, it will consume a policy file, which will tell you what you want to measure. It will measure those into the TPM and then execute your target runtime. And with that introduction, I will turn it over to Daniel to cover the status on upstreaming. Thanks, Daniel. I would like to discuss how this idea of the trench boot map to the current upstream project, but at the beginning, I would like to say something about history of the project. The project was initiated by Aperture Solution and the company invited the corporation, Oracle and FreeEmbed. FreeEmbed is a small company in North Park of Poland, which focuses on developing open source firmware for embedded platforms. And in general, Oracle focuses on Intel implementation of trench boot and FreeEmbed focuses on DMD implementation. So how this whole idea of the trench boot project applies to specific projects. First of all, the grab. It was decided to provide a DCE PRAMB for the grab at first, because this is the most common bootloader in current deployments. So we are working currently on this project and we have to do some changes in the code. First of all, we have to extend the Linux boot protocol with a special additional kernel infrastructure, which I will discuss a bit later. We have to also add some additional commands to identify the secure launch phase and additional commands to load the DCE modules for Intel and for AMD separately. And we also have to add some DL event relocators, one for Intel as enter, another one for the AMD SK in it. AMD development is farther along than Intel currently. We haven't published patches yet because currently it doesn't work simply. We do some tests. We have some difficulties with Intel, quite big difficulties with Intel, but if everything works, then we will release the first version of patches. Assel boot. This is a small piece of code which we took from the T-boot because we needed something to test which will work, let's say, almost out of the box. So we decided to just strip T-boot, remove all unneeded pieces and just leave a pre-launch code. This solution just worked on Intel because T-boot was developed on Intel and this is interim solution. We currently have this code running. We have currently system boots, but there are some problems with network or something like that. So currently working on that. This is interim solution. We are going to move all that code to the grab and post it upstream. The kernel info patch. I was mentioning this thing in the grab slide. We have to change Linux boot protocol because we have to pass some information from the kernel to the bootloader. In particular, this is entry point to a secure launch code which will be in setup part of the kernel. And after discussion with HPA, who is maintainer of Linux boot protocol, we stated that it is needed to extend to extend the protocol by adding kernel infrastructure. We have to do that because currently setup header has very limited size and we are using just final bits of this structure. So after some discussion with him, we decided to introduce this new structure which will not have such limitations and can be extended in the future without any issues. And I have posted two patches on Linux kernel mailing list, HPA is quite happy with the implementation, but he has still some comments and I'm going to take into account his comments in version number three. Secure launch phase, this is a code which will be put into the Linux kernel. Currently there are two sibling patches in development. Intel, sorry, Oracle together with our Aperture solution focuses on the Intel TXT implementation. And I am there, Secure Stoplight implementation is done by free embed with some help from Aperture solution and Oracle and as I know with AMD currently. Summary of changes. So we have to introduce some changes into complete part of the kernel. First of all, we have to introduce SL entry point and minimal code to handle entry from DL event. We also have to add some minimal implementation of the SHA and the TPM. But and this code currently exists, but after some reviews we realize that this is possible to optimize the TPM logic and make the code smaller. And we also have to add some code to the processing of handover from DL event in set up part of the kernel. And Uroot stuff. Uroot is a project made by Google and it is just a simple in-e-tra-matter phase for DLME. And we will call it a security engine for first launch. We have to add a unit app that functions as a core engine for processing a policy file which describes evidence collectors, attestors and what launcher to run. We have to add a measurement library that provides a core set of evidence collectors. And we will be using currently existing boot capabilities in the Uroot to implement a Kexec launcher. And we are going to provide attestation in DLME in later phases of development. When we discuss the project among the people it appears that there are more and more features needed but we are not able to provide all of them at first step. So there is growing to-do list. And first of all, first thing which I think is worth mentioning is extending the Kexec with DC preamble implementation. This way you will be able to restart dynamic launch from the running OS. Also we are considering adding DC preamble to the IPXE and also we are considering extending some things in Zen. We are going to make it to be executed from the Kexec as a DLME and we are also going to add DC preamble to the Zen which I think is quite interesting idea. So that's it. Questions and answers. Hey, so you mentioned being able to get away from having the boot firmware as part of the TCB. What's about EFI runtime services? So you don't necessarily need runtime services, right? Yes, you do. For what? P store, changing boot configuration, primarily those but there's a few other cases where, oh, firmware update. You're going to need to be able to use boot services and runtime services in order to configure the firmware update on next reboot. Right, but do those operations have anything to do with the execution of your operating system that you're running? In that calling them if they're malicious could result in the firmware tampering with the state of the kernel after your measurement. Right, so at that point you're discussing a runtime issue as opposed to a boot time, right? I've established the integrity. I didn't rely on the firmware to establish the integrity of my operating system. I relied on the CPU to establish the integrity of what got loaded. That's my load time integrity problem. Now if you want to tackle the runtime integrity problem that's a much larger problem, right? It's very difficult, right? You have to be able to inspect things and decide afterwards whether or not, after things have started executing and things have changed in terms of the state of the application you have to be able to inspect that and make assertions about that. So yes, that problem is not a dynamic launch problem. That is a platform problem period. It doesn't matter whether you've done only an SRTM boot or if you've only done a dynamic launch boot. If you've got corrupt firmware, you've got corrupt firmware, whether it was corrupted as part of the launch or it was corrupted after execution. It's still a runtime problem. So is the model that's even in a dynamic launch environment how you should be looking at the SRTM values as well to make it a totally off the platform? You should always, because you're trusting the SRTM to have initialized the platform, right? So you still have that. We try to minimize that as much as possible with the dynamic launch, but at the end of the day the sec phase is what put the memory timings in there. If that was corrupted and it decided to screw with that you're done, right? There's nothing we can do. So we still care about the SRTM. But the key point here is that we want to remove and reduce the trust chain that was used to launch your operating system. So we're trying to increase the integrity in the platform, but it's a holistic problem. That's the whole point that we talked about in these routes of trust. I shout away from it, but the fact is is like, the trust is there. You can't drive it to zero, right? You can't decide that it's optional. It's there. It's the question of whether or not it's an implicit or an explicit trust. If you're only gonna be implicitly trusted then you might as well just implicitly trust the entire platform. We care about trying to make that trust explicit. We're trying to create contracts between us and the hardware to make sure that everything in the running state is correct as best as we can. Thanks. If I may add something, as far as I know you are able to avoid some runtime services calls. For example, some companies try to avoid these calls which are needed to change the boot order of the platform by using external device like a BMC and a variable to set the boot order of the machine using open BMC or something like that. Then you are not able, sorry, then you do not need to use runtime services to change that order. But in case of P store, of course it is much more difficult, I think. I guess a couple of things. Let me start with the runtime issue. You may, I'm monetizing, by the way, from... Okay, yeah. Sorry, no, something about this. You made a statement earlier about the SMI handler. Yes. So that's up to the OEM, Intel TXT does provide support as of 2015, I think, support for the STM. It's entirely up to the OEM as to whether to provide it. There is some open source STMs available if that's an area of your... To me, the SMI handler is much scarier than the runtime UEFI handler. So that's the thing I'd be worried about. Oh, I agree. Yeah, so I just wanted to make that correction. DL entry is the generic term that we used in the spec for S-Enter, so they're synonymous. Didn't want to put S-Enter into an industry standard specification and there was one other correctional automate by trying to blanket it right now, but I could probably give you some help in this area if you would like. I mean, yes, you're correct. So just a touch on your point. So for those that aren't aware, there is core boot. They actually are implementing TXT support as well as STM support. So what Monty was touching at is the fact that when you do a dynamic launch in S-Enter on an Intel TXT platform and you have an STM present, the ACM will actually interact with the STM to establish the integrity of your SMI handler until all more mainstream providers adopt that, DL, HP. We don't have anything that can handle the SMI. Everybody is beholden by the SMI at this point, the handler. All right, any other questions? Any comments? Comments? All right, thank you very much. Thank you guys.