 Wow, those lights are bright. Hi, my name is Ron Minnick. I work at Google. And my talk today is about replacing your exploit-ridden firmware with a Linux kernel. Now, for the past 10 years when I've talked about firmware, people have gotten used to assuming that I'm wearing my Corbut hat, which is a Corbut hat. It's a very nice hat. I am not wearing my Corbut hat today. This is very much not a Corbut talk. We have a couple of partners I need to mention. Tour in the audience here today, Sean Marie Verdonen. And I'm going to slaughter the names with my terrible accent and Guillaume. And we have several people who've worked on this at Google and then Tramel Hudson from Two Sigma, who's been very important. And Andrei Merchowsky at Cisco, who helped a lot with the Go part, I'll describe in a bit. Going to start with the results. We had a Facebook compute node, which I'm calling the OCP node, up in our booth. And we got the booth time from eight minutes to 20 seconds. And to be honest, to my way of thinking, that's maybe the single least important part about this work. And you'll see why I'm saying that in a minute. All the user land is written in Go. So we have a kernel and an init ramFS in Flash. And the user land for that init ramFS is all Go, including init. This brings Linux performance reliability. And I forgot to say security to firmware. And a key point of this, and you'll see what I mean by this in a minute, is we eliminate all of the UEFI and ME post-boot activity. Here's the problem. When we began Linux, we all joined it in the 90s. It controlled everything about the x86 platform. It was classic Intel 586 processor. But where we are today, between Linux and the hardware, there are at least two and a half kernels. And they are complete proprietary and, not surprisingly, based on that, they're exploit friendly. It's pretty easy to write exploits for these other operating systems. These run at a higher privilege level than Linux. They can control and manipulate Linux. And those exploits can persist. So unlike the kind of exploits where you write something to the disk, and we can always get out from under that by formatting the disk, again, these exploits can be placed in the operating, the motherboard flash. And you're never going to get them out. So once they're in there, maybe one of your options is you shred your motherboard, because there's just no other way out of the problem. I used to give this talk. And the title was, if you trust your computer, you're crazy. Fortunately, hopefully, I'm going to talk about ways to deal with some of these problems. So we can stop being crazy and maybe get a little sane. So here are the operating systems. And there is the one you're used to, which is ring zero Linux. And then there's ring minus one. We call that ring minus one. It's never really been ring minus one. But basically, we kind of ran out of ring numbers. So fine. It's ring minus one. And so we've come to call the other two, ring minus two and ring minus three. The ring minus two, kernel and half kernel, control everything about the CPU. I call system manage mode a half kernel because it traps the 80, 86, 16 bit mode. Every time you close your lid or do certain other things on your Mac or on your laptop, it's probably trapping to 80, 86 classic 16 bit mode. That should make you happy, right? No protections at all in that mode. And then there's the UEFI kernel running in 64 bit page mode. And sometimes things trapped SMM and pop out in UEFI. So Linux isn't even running at that point. And then there's ring minus three. And this is the one that has people really worried. This is, there are three 80, 86 CPUs on your die usually. One's called the management engine and that's the one of concern. The other one is called the integrated sensor hub. We're not gonna worry about that today. And I don't know why I really love the name of the other one. It's the innovation engine. I just, every time I say that, I kind of have to laugh a little. The ME though runs Minix three. And that's why this is the year of Minix on the desktop because if you add up all the nodes running Windows and all the nodes running Linux, that's less than all the nodes running Minix three, which I guess Andy Tannenbaum would like to know. What's in ring minus two and ring minus three IP stacks? And there's no common code between these as far as I can tell. File systems, drivers, disnet, USB and mouse. Why do you have to have file systems in the ME cause it can reimage your node? Web servers, there's a web server in the ring minus three 80, 86 running Minix. That was the result, you know, that was the thing you might have read about a recent exploit with a zero length password giving you full admin access to your machine. And again, these things can reimage your work station if it's turned off. If it's plugged into the wall and turned off and on a net, it'll get re-imaged maybe without you knowing it. Here are some of the components of the management engine. I can't claim I know what all these do. I can't claim to understand why there's full network manageability, regular network manageability and manageability. I don't know why, you know, small business technology is in there. What small business technology meant originally about 10 years ago is it's really inconvenient to set up passwords so we just don't have a password for the ME. There's a thing in there called the Outbreak Containment Heuristic. I don't know if that comes from the movie. And then the Protected Audio Video Path, which at least some people claim to me means DRM for audio and video. Here is a, and these slides are open and I'll mail them to you if you don't catch them. So don't worry about copying this, but Facilius Riveraus about 10 years ago did a fantastic master's thesis on ME flaws. And it was kind of depressing because basically everything could get attacked. And not all those have gotten fixed. So just for fun, you can Google Intel ME exploit. 50 million hits, I kind of enjoyed that. And the wired headline was pretty funny. Intel fixes a critical bug that lingered for seven dang years. You know, and if you do the math that's kind of like kind of a billion machines. And you know, the fix is just reflash your firmware. Now how many people want to believe that a billion machines have been repatched since last spring with new firmware to fix this bug? I certainly don't believe it. I think I'm sure that bug is still out there and the web servers are still out there and you can still send a lot of them zero length password and have admin access. The ring minus two half OS was originally used for power management. It came in with the 486. Here's the problem. I have a laptop based on a 486 running DOS and I closed the lid and I wanted to sleep. DOS isn't gonna do that. And so what they did is add a very high privilege mode higher privilege than ring zero that sort of can take over the machine when certain events happen. They're called system management interrupts and that stuff can take certain actions. And you know, can't really go into all the details. It's a pretty long story but all kinds of interrupts can go there. So back in the day, you had a kernel that didn't support USB and you plugged the USB mouse in it and it worked. It's because of a full USB stack that exists in system management mode. Independent of every other piece of code you've ever seen. And that's why sometimes maybe you'd plug a mouse in and it wouldn't work because USB stack didn't support that particular mouse. Are there SMI exploits? Yeah, there are a lot of SMI exploits. And the big problem with SMM is the way in which it works is once enabled, you can't turn it off. As part of enabling it, you set a bit that essentially takes a big chunk of RAM and makes it invisible to every other operating mode. So it kind of, it's a cloaking device, right? It just vanishes. This memory with its stuff in it. So you kind of can't really know what it's gonna do. You can't disable it. You can't turn it off and it's hidden. So it's a good way to maintain vendor control over you. And finally there's ring minus two, which is UEFI. That runs on the main CPU along with SMM. This is an extremely complex kernel. And I think one source of the exploits is that a lot of people that say vendors are writing against this kernel and don't really know other rules and they make mistakes. And the result is that there are big giant holes that people can drive exploits through. For the most part, UEFI, from what I can tell the security model is obscurity. How many people here have written code for UEFI? I'm just curious. Oh, that is a lot. Okay, did you like it? Okay, so I never liked it personally, but I'm just curious. Are there UEFI exploits? Oh my gosh, there are UEFI exploits. And kind of the weird thing about UEFI, the model has always been that it's so darn smart that a kernel can sort of drop random bits of UEFI update into memory and then pull this chain and UEFI will update itself perfectly. There are no bugs in this process. And of course there are bugs because we all write code with bugs. And the worry for me has always been that we get an exploited UEFI written and then we go and say, hey, I don't like your UEFI update yourself, but it's an exploited UEFI. And it says, sure, I updated myself, but it doesn't. So the worry has been that you can make an exploit that can't ever be removed. And again, the only remediation is a shredder. Here are some of the UEFI components. This is on the OCP node, which is a pretty limited node. I am told that there can be hundreds of these. And just look at some of this stuff. There is USB stack. There's an IPv6 and IPv4 protocol stuff. Has anybody here got a machine with an ISA bus? Just curious. There's ISA bus support in case you find something from long ago. There's just a lot of stuff in there, IDE. And all this stuff is polling IO driven. It's got lots of delays build-in. Okay, it's very, very primitive drivers. And that's one reason it's so slow to boot. So we've got these two and a half hidden OSs. They have a lot of capabilities. They have network stacks and web servers. They implement self-modifying code that can persist across power cycles and reinstalls. They hide, have bugs, they can control Linux. And my reaction and exploits, of course, have happened. And so this is where my old talk used to end, right? Are you scared yet? If you're not scared yet, maybe I didn't explain it very well because I sure am scared. I think this is a bad situation. So how do we fix this mess? Now, I've actually, or everyone's smile, someone comes to me and says AMD. This isn't a problem on AMD. That's completely wrong. It did not used to be wrong. It is wrong now. You really can't just move AMD and have everything work. People say to me, but Ryzen is totally open. That's only partially true. Some of the weirder bits of VFI on the AMD processors are moved to something called the platform security process or the PSP kind of brings up DRAM, not the main processor. And the PSP code to bring up DRAM will never be released. So kind of AMD is more open in the things that are open, but it's not open in a sense of things closed on Intel are still things closed on AMD, if that makes any sense. So we're focusing on Intel X86. And partly that's just my bias. That's the processors I use. And the goal here is to reduce the scope of the two and a half OSes, and I will say that a lot of what we're doing here will apply to AMD processors, just not the management engine parts. This project is called NERF. UEFI stands for Unified Extensible Firmware Interface. We consider extensibility harmful. So NERF stands for Non-Extensible Reduced Firmware. Whoops, wrong way. The goal is you make firmware less capable of doing harm. You make the things that does do very visible. We get rid of all those runtime components in the management engine and UEFI. And in particular, it's hard to kill everything the ME does. Your node won't turn on in many cases, but we did take away its web server and IP stack. Good thing to do in my opinion. And we also removed the UEFI IP stack and other drivers it might have. And finally, we removed our ability to reflash themselves. We don't want them doing that, so they don't. Linux should manage this stuff, right? There are probably 30 million plus Chromebooks out there, and when your Chromebook gets a new BIOS image, Linux reflashes that image. That works. I haven't heard of any problems like we had with EFI where someone tried to boot Linux on EFI and brick the machine. That used to happen a lot. It doesn't happen with Chromebooks. So the pieces of NERF are a D-blabd ME ROM, a UEFI ROM reduced to its most basic parts. We disable system management node or we vector it to Linux, a Linux kernel, and then a user land written in Go. And for anybody here doing Go, we really welcome anyone who wants to join just the Go part of this project and nothing else. So being part of and contributing to this project doesn't mean you have to be a kernel person or a firmware person. There's a significant user land activity, too. So we don't want the ME at all. You can't get rid of the ME. It's on the die. The ME is the first thing that turns on when you turn on the chip. The ME starts all the clocks up. On the later processors, there's a reset vector. The main CPU fetches it. The ME feeds that vector to the CPU in a lot of cases. The ME is not going to go away. It's there for good. If you remove the ME firmware, your node may never work again. It may not turn on. In a lot of cases, it'll turn on and turn itself off in 30 minutes. And the idea there is the ME says, something's wrong with firmware. I'll give you 30 minutes to fix it. And then I'll turn off. So you really, really can't kill it. But two and a half years or so ago, Tram Hudson started looking at the ME firmware. And he learned a lot about it. And since that point, there have been other people breaking this stuff open. And boy, we've learned a lot. But the big thing is, Nicholas Korna wrote a thing called the ME Cleaner in Python. And on a neat little system like the MinoMax, this $159, I really love MinoMax's board. It has an 8 meg flash. Believe it or not, 5 meg of that flash is just for the ME. If you run the ME Cleaner on that thing, 300K of it is left. So out of that 5 meg, you really only need 300K to boot Linux on that platform. And again, it removes the web server and the IP stack. And all those things you really don't want it doing. I should mention that server platform is not completely solved. If I run a ME Cleaner on the OCP node, OCP node won't turn on. Don't know why yet, but that's something we're going to plan to work on in November. Here's what the components of that ME image look like on the MinoMax. You can see BUP, bootup, kernel. I assume that's Minux 3. There's some interesting names in here. Policy, RSA, FPM, just random stuff that kind of make you worry a little. Because one of the things that people have found is there's a fair amount of zero days in anything related to networking in the ME, as well as in anything related to RSA. On the OCP, this is what it looks like. Again, see the funniness there? There's BUP and BUP. So it's kind of like a BUP that kind of is there for a lot of stuff, and then sort of, I guess, a sub-BUP that also has to run. And the ME Cleaner seems to remove everything after the first BUP, and that's why it won't turn on. So that's the ME. And we've made that work on the MinoMax and a number of other boards, so let's move on to SMM. If you get into the game early enough, and we think our Linux kernel is getting in early enough, we can completely disable SMM. Now, back in the day when we had Linux BIOS, which is the 1999 to 2007 or so name for Coreboot, we ran thousands of compute nodes at Los Alamos with no SMM. And we had a nice conversation once with an x86 vendor who claimed that it was impossible to run a server node with SMM turned off. And we said, well, you'll have to talk to Linux networks about their 100,000 servers they've sold with SMM turned off and explain to them that it can't work, but it's working fine for us too. So as far as I know, there's no requirement in most cases to run system manage mode. It is there. Vendors use it to do value add, which means stuff that locks you into that particular vendor. I don't think we need it. But let's pretend we have a node for whatever reason that it turns out we have to have it. I've worked on, I've developed some stuff that allows you to vector an SM interrupt into the Linux kernel. So this is kind of nice, because the SM interrupt now becomes like any other sort of interrupt. And we can manage it in Linux, not in hidden code, off somewhere in the chipset. So we kind of have two approaches. Kill SMM or vector it to Linux, but keep Linux in control is the theme here. Onto UEFI. UEFI is huge. It's extremely complex. We find a lot of errors in programming of it, just for that reason. There are some things that still seem to need to go there on some platforms. So single error correction, double error detection interrupts seem to want to go to UEFI. Maybe that's not as true as it used to be, but it's possible. But we really want to remove all the opportunities to put exploits into UEFI, and that remains removing most of UEFI. So it was the unified extensible firmware interface. We make it non-extensible. Here again are some of the UEFI components. By the way, that digital thermometer sensor, that's not a typo. That's right out of the thing. I don't know what a thermometer is. Maybe someone here knows, but I haven't quite worked it out. Here are some of the UEFI components. And this is an iChart, and you won't be tested on this, and you probably don't even want to know. But there's a lot of stuff here, right? And if it looks like a kernel, well, it is a kernel. It's a big kernel. It's actually a sizable fraction of the size of Linux. So here's what we do. Here's the standard UEFI boot steps. Over here is the security phase. In security, you kind of start up in 16-bit mode and do some other things and verify the processor and chip set in it and board in it bits. And this is where lots of stuff happens that you are never going to find out about. That's just highly proprietary stuff. The vendors hold this very tight. They don't even distribute information about what this means widely in the vendor. But here's the neat part. They've done a good job with that interface. This is a very well-defined interface. Documented, all the code follows the rules. And this is the so-called driver execution environment. This thing conforms to that interface. All these DXEs conform to it. And this thing called the boot manager conforms to it. And the boot manager is just another kind of DXE, the big difference being that, notice, these all have an arrow coming back and that one doesn't. So it runs a bunch of these, then it pops into this, doesn't expect it to return, and this guy loads your OS. This red box here, you could think of as grub. Here's the thing that should worry you a little. Final OS environment, runtime, what is that? Well, that's an EFI OS present app. Again, when Linux is running, EFI is running. And that's the thing we don't like. That's the thing we're trying to get rid of. So again, I mentioned that that boot manager conforms to this well-defined interface. So what we do, we build a Linux kernel that conforms to that well-defined interface, and we replace the BIOS with that. I guess everybody here has booted a PC and seen that big screen that says what do you want to boot from and what time it is and all that stuff. That becomes this Linux kernel. So you pop into the Linux kernel and away you go. And on the node upstairs, it's about 20 seconds. We timed it again yesterday, not eight minutes, 20 seconds. And again, on the node upstairs, what we have is this Go-based user land, and the default action of that is to run a DH client, a Wget to get the kernel, and then a Kexec, all that stuff's written in Go. And that's about a three-second process, over 100 megabits to a Raspberry Pi. Now, Tram's been leaning on me really hard. And so as a result, this is actually a different talk than it was a week ago. Tram keeps saying, hey, this actually exists in an open-source form. You should replace that. And so we've decided that's what we're going to do. And so this is an open-source thing that is slightly modified so that it really knows how to boot that even faster. And we think we're going to be able to shave that 20 seconds down to a lot less time, which I think is all to the good. So that's where we're headed. So again, we can't fix this stuff. This is what we did in the old days with Linux, BIOS, and then Coreboot. We rewrote this. Even on Chromebooks that run Coreboot, that nowadays is a binary blob. And we're not going to get that stuff again. I really don't see how it's going to happen. So the only real option is to put ourselves, so I'm not doing so over this point, or put ourselves right there at the line that runs through that green Dexie core oval. So as I said, we can fix this problem partially, but partial is better than nothing. And we can get rid of all the runtime components that come with EFI. And that's really the goal. So how do you rebuild bits of EFI? And again, these slides are going to be distributed. You don't have to type real fast to try and copy them. Tram's done some real nice work with building a kind of set of make files and things to automate his head's thing. And part of his head's thing is part of what we're doing with Nerf. So we're going to be building what he does to allow you to really kind of automate building a Nerf image for your motherboard. We've had some good results on a Dell R630, as well as the MinoMax, as well as the OCP nodes. So anyway, that's kind of where we are with this. So using Linux makes firmware a lot easier. If you're ever done firmware, you know that with every little board, there are all these tweaks you have to do. I mean, the simplest one is there might be on an AMD, a GPIO. And that single GPIO on an IO bridge is used to turn on memory, let's just say. I've had cases where I have five different boards from the same vendor and every time they use a different GPIO. So even trivial, trivial changes make your life really difficult. But what is another nice thing about that defined interface we have is on the right side of the interface when we start Linux, that's a pretty standard x86 platform, and it's functional. So we thought for a long time we were going to have to finally tune the kernel for each of these boards we're on. I've used the same kernel for the MinoMax, which is a tiny thing, and the OCP, which is a very big thing, and it's worked fine. So this actually makes our life a little easier. One of the participants, Ryan O'Leary, wanted me to mention, actually, that what he wanted me to mention is no longer true because of change in plans. We were slightly tied to the BIOS vendor because of ACPI setup. I think some of those issues are going to go away. So I wanted to just talk a little bit about user space. Our user space is written in Go, and there are a lot of reasons for that. We tend to trust Go a lot more than C at Google. It's really viewed with favor. If you can have a thing in C and instead have a thing in Go. I spent many years with BuildRoot and BusyBox and all those things, and I started this Uroot project about six years ago when I had yet again another BuildRoot failure, and I just got tired of trying to figure out all the config scripts and stuff. So all our commands are written in Go. And in mode 1 for Uroot, in fact, when we build an init ramfs, it includes the Go tool chain. All the packages needed to build all the commands, all the command source. And when you boot, and then commands start running, they're dynamically compiled. It typically takes about 200 milliseconds to build a command like bin date. Since we're putting this in a ramfs, after that, it's just essentially instantaneous to run. So that's the security guys really like this because you bring a machine up and all the source is visible, and we kind of bring along everything that's needed. But it's a 5.9 meg init ramfs, even LCMA compressed. So sometimes there just is not enough room. And so, or you've got a really slow processor like NRM, and you really don't want to get a compilation step, even a fast one in a way of booting. So we have a different mode. We have one program in many sim links, which should be familiar to anyone who's used BusyBox. So it's kind of a multi-point binary. So you type ls, and it actually runs the same command. It looks at argv of 0, and then calls a function named ls. And what we do here is we use the go abstract syntax tree package to rewrite commands in the packages. So I have a command called ls. It's package main. We actually parse that with ast, and rewrite that to package ls. Get all those packages. We compile them all into one binary. That takes 15 seconds. Now, the thing about go is every compiler instance supports all the architecture and OS combinations you can think of. So you never do a cross-tool build again. You get the go compiler. If you want to compile for arm, go arc equal arm, run your compilation. You've got an arm binary. So that's really kind of handy. In this mode, of course, we don't include the source code or the tool chain, but it does reduce the footprint to 2 meg. And this is really handy, again, when FlashSpace is limited. There's kind of an interesting implication here for startup, which is that all the init scripts get replaced with one go program, one or two. And that leads to things coming up really fast. And at least from my point of view, I don't need to look at unit files and scripts and stuff. I look at one program for whatever platform I'm on, and I understand that the boot up, and it's really fast. So we actually have a project for Chromebooks where we can boot to x11 in a browser in five seconds. And this speed is part of that. So I don't know. This is leading to some other thoughts about maybe how we do things in normal machines. We just basically use go to write the init thing, and we're done. So go is a compiled language, but it's frequently used for scripting. That's why I use it all the time. I stopped writing bash scripts years ago. I just write go programs. It's actually easier and more reliable. So anyway, I kind of pushed a little hard to get through this because I wanted to cover questions. I literally have to leave here right at 5 o'clock to catch a taxi. And I just wanted to see if anyone had any comments or thoughts or questions about this project. Where we are going is we hope in 2018 to have some actual companies using this and shipping those with this embedded in it. And the reason they want it is they want to have firmware they understand, and it has a fast boot and is secure. And with that, I'll stop and see if anyone has any questions. Oh, yeah. Yeah, so we don't do secure boot. And I think if we use TPM, we'll probably try and look at how Chromebooks do it, because that's worked really well. There is a verified boot written in Go that's part of your route now that doesn't work, I must say. But we'd really like to look at going the track that Chrome OS took with their use of TPM and not the secure boot stuff. And to be honest with you, you're skirting right at the edge of what I really understand, so that may not be as good an answer as you'd like. But it is something we definitely will be looking at how to handle that. And Tram is, I should say, Tram is very concerned about this. Heads is part of a secure environment that he's building. And he really has a much better understanding of measured boots than I do. So to some extent, I'm going to follow his lead. But that's a good question. Oh, yeah, I'm back here. I'm sorry, core boot is not in here. No, so here's the mic. My take on this is that core boot is always preferred. I always prefer core boot, right? So on the minimax, when I can run core boot, I do. But there are situations where core boot's just not going to work. Core boot has not been on server platforms for 12 years because of this problem, because we couldn't get the information on how to turn on QuickPath. So we're back on server. And I think that's the important thing about this is we are now back in an area with sort of open sourcing the bios as deep as we can and on server. And that just hasn't been true for a very long time. So that's my idea. Always use core boot if you can. If you're stuck with a situation like this, look at Nerf. That's how I'm attacking this. Yeah? Microcode updates. We don't. Question was about Intel microcode updates. Here's the issue. On many processors now to turn on DRAM, which is essentially a billion instructions for the training step, you have to have the right microcode loaded. So that microcode load has to happen in that second thing, that PEI step. So there's nothing we can do about that, right? If they're going to turn on DRAM, they need the microcode that makes DRAM work correctly. And that happens before we get into this DXE level. So we can't really do much about microcode. So any other questions? Oh, yeah. I don't even know if this mic works, actually. I haven't tried it. Does this? Yes, this mic works. So more of a general comment. A lot of things that you seem to be complaining about aren't part of the EFI specification, but rather things that vendors have done that are suboptimal or horrific, like the use of SMM for things that should never be in SMM, enabling tons of modules in their EDK2 build that are unnecessary and that kind of thing. Because you can compile out all those. Sure. The vast majority of those modules in EDK2. Well, you can compile the Dixies that source is available for from a vendor for their network card, say. If they don't give you that source, you're stuck. And we have enough of them. And further, I mean, it's a good point. Yes, you can fix a lot of this. But the counterpoint is take a company like Google, which in published terms has at least a million machines in its fleet. The Google Linux compiler is tested at scale 24-7. When we boot EFI, it's very infrequent. So that testing is not nearly as strong. So I think there's a really strong case to say that that kernel that is so heavily tested and made performant should be the thing I put in firmware. That's my argument here. And I've had good results for that since 1999. So I'm buying that argument. But I take your point. But if you look at the Power 9, for example, IBM Power 9, they put Linux in firmware. So this is not really, I have to say, this is not a novel idea. It's a novel for x86, even though we've done it for a long time. But it's not an awful idea in general. Just one follow on from that. The bits that you said you had a repository of open source bits for the firmware. Have you interacted at all with the EDK2 open platform package where they have lots of they're trying to upstream open source platform support into EDK2 for a variety of ARM and x86 platforms? Yeah, I think there are a number of companies as an entity that are doing that. And I think there are people at Google doing that. I also think that when we kind of look at the overall picture, at least me personally, I shouldn't say I'm speaking for Google at this point, Linux, to me, makes far more sense as the thing to start at the end of PEI than UEFI. Oh, sure. I just meant for the bits that you mentioned that you had open source. Yeah, Tiano Core. And again, to Intel's credit, Tiano Core was open sourced. And there are a lot of pieces there that actually we use. The Dixie Core and there are two utility programs. But in the end, we want to get into Linux and firmware as soon as we can. Fair enough? Yeah, thanks. Did you have a question back there? No. OK, yeah. So for me, as a normal user, I'm not talking about servers, platform, other things. I have my notebook. Can I use this without having access to the? Yes, Tram is actually targeting notebooks. And is that your question? Yeah, and what exactly do I need for this? Because if I go to the vendor and ask, OK, can you give me a source code for your UEFI, ME, and other stuff? No, no, no. You don't need source code for UEFI at all from the vendor. And what about ME? You can never get source code for any ME anyway. Can I just replace it with? So the ME cleaner, you're not going to replace it either. The thing I didn't mention, I'm really good at this, the BUP, that very first thing, that is signed. You can't change that or things won't work. So it's all the stuff after the BUP that is not included in that signing. So what we're doing is removing all the stuff that's not part of that signed thing. And that's when we discovered that if all that's in there is the BUP, platform comes up, doesn't turn off after 30 minutes, everything seems to work fine. That's been the big discovery of the last two years, which none of us ever thought would happen. So you do not need the ME source from your laptop vendor. You need the ME cleaner from KORNA to clean it. You do not need UEFI source. You want to talk to Tram Hudson. And I should say, part of this discussion of KORBOOT or NERF, Tram was working really hard to kind of get KORBOOT on a lot of things. And it's just a tough lift, because that information is so tightly held. I think he's finding this NERF approach a lot easier and more approachable. But again, you do not need source from a laptop vendor to do this. Tram has done it. And if you want to talk to us later, we'll try and help you do it. Now, if you're going to do it, make sure you're OK with the idea of turning your laptop into a brick and recovering from that, because it's still early days. And any time you do this stuff, that can happen. Purism released some. Purism, the notebook, released something that they disabled Emilinos completely. Yes, I know that guy very well, actually. They said it's not gone, but it's simply disabled. So speaking about this web server that you said is still a problem. So the ME Cleaner removes all that code that implements the web server. The Purism work actually goes a little deeper and turns on this HAP mode, which is really pretty cool. So what's happening as a result of the, again, the last two years of work by a lot of really good people, we're slowly, slowly digging our way into basically disabling the ME, which I think is something we've all wanted for a long time, and I think we finally are learning really how to do that very effectively. That's the big goal. But Purism's work is, you don't want to view it in isolation. Purism's work is sort of part of this continuum of work. And everybody has been contributing, and it's sort of the next step in this work we're all doing to try and get it. I shouldn't say me, I haven't, it's other people doing this great stuff, but the community has been doing to get this disabled. And another question, is this ME cleaner or the possibility to clean that up, also working for the newest Intel processors, which is science stuff? I think, but we'd have to, I'd have to find out. Honestly, again, all this stuff is moving so fast that weekend and week out, there's sort of some new discovery and some new way of turning more stuff off. So it's been really fun to watch because we really didn't know we'd be able to do any of this. So yeah, I guess all you can do is watch events. Like I say, this was a different talk a week ago, because we're learning more and more day in and day out. Fast moving project, and we'd love to have anybody who wants to get involved get involved. So, yeah. I'll repeat your question, cause, oh, that's okay, yeah. I have two minutes and 54 seconds left. Just a follow up on what he asked. The disablement is actually working cause the Skylake stuff. This is an x86 core for ME and a Minix kernel. And there's been security research on just decompiling all ME. And they found an just disablement bit. So you can just flip a bit and everything after the boot up is gone. And the old ME cleaner works on an obscure risk architecture and that won't work on the old stuff. But if you've got a Skylake and Kaby Lake, you can just disable ME for good. So I just got told in no uncertain terms to stop. Thanks all for attending. And we again, I appreciate anything you want to do for this project. Thanks. Thank you.