 Hi, fawr. I see we have some people. Who here knows about EFI? Good. I'm hoping people out here know more about it than I do. This is not a lecture, it's a bof, I want discussion. The reason I've set the session up is that I can see we really need to think about EFI and what Debyn's going to do about it. I'm going to end up probably implementing a good chunk of it, so I don't want to be taking the blame for decisions that you lot don't agree with. So if you're here, it's your fault. Again, I'll ask, who knows anything about EFI? There's two parts to it. We need to actually deal with installing and booting on EFI itself. That is not actually that hard. We already have this load of how-to's and everything on making Debyn do it. We don't actually do it yet on our installation media, but it's not that hard. It's not trivial, it's just a matter of programming. We can deal with that. The more interesting part of this is this big scary secure boot thing that everyone's been weeding and writing about in the last few months. We have several options on how to do it. I don't think there are any good options personally, but I'm prepared to be convinced otherwise. There are two obvious ways that we could follow that other people have already followed. The Fedora people, as ably described by Matthew Garrett, have gone with getting their kernels, their boot media and everything signed so that it will work on PCs using Microsoft's secure boot and Microsoft's key. Ubuntu have done something different, which I'm hoping Steve will tell us all about. Oh, you mean now? Yeah. Brief overview. Sorry? Brief overview please. Brief overview. So secure boot is important to the Linux ecosystem in general on account of the fact that by the end of this year we should expect new hardware to be coming out of all of the OEMs in the PC world, so x86 computers that are shipping with the intent to run Windows 8 and Windows 8 certification requirements stipulate that secure boot must not only be implemented but must be enabled by default on any machine coming to pass the Windows 8 certification, which means that when Joe user buys a computer at Best Buy and preloaded with Windows 8 on it and they try to install Debian by putting a CD in or a USB stick or whatever it might be, by default what they're going to see is they're going to get an access error. And so this is important for us to figure out how we as a community are going to deal with this so that users can still continue to install free software on machines that they purchased and should have the right to do that on. Now the Ubuntu approach in particular has been to do our level best to prevent the user from having to do anything to fiddle with their firmware settings in order to be able to boot, which means going along with the secure boot key regime which Microsoft is putting in place, Microsoft has said they will be a CA for secure boot for other vendors so that other operating systems can also boot on PCs. And so we're in the process of trying to get that going so that when you drop an Ubuntu CD in a UEFI secure boot machine it will work out of the box with no fiddling. Now in particular one of the things that differs between what, well there are two main things that you may have heard differ between what Red Hat is in the process of doing and what Canonical Ubuntu are in the process of doing. One is that Canonical has on the basis of the legal advice we've been given made the determination that we're not persuaded that it is safe to use GPLv3 bootloaders in this signing chain for fear that one of the remedies that a court might order is that we would have to disclose our private keys. Now there's been lots of discussion on LWN and elsewhere about whether this is actually a concern. However, we're going with the best legal advice we've been given at the moment which is that this is a concern and therefore we've opted to use a non-GPLv3 bootloader and we're implementing menu supported in FE Linux instead. Now the second difference is that whereas Red Hat Fedora are saying that they are going to do full signing of the kernel stack which means that only signed modules can be loaded into your kernel we are presently avoiding going down that path because we don't believe it adds any additional security value and we are trying to avoid having to do that because it does make it a lot harder for a distribution to rev kernels. It makes it harder for, for instance, any sort of DKMS package to work in a distribution any sort of package where users might be building their own modules or doing the final linking of their own modules and that obviously is going to invalidate any sort of a binary signature on those kernel modules and therefore it doesn't work if you have a security model that requires all of the binaries to be signed by a key that the user doesn't control. So I think that's... Before you switch to another topic what you said about the GPLv3 license is not the view about the FSF which is also the upstream for Grubb, I believe? I'm sorry, I have a hard time understanding. Can you remove the microphone away from your mouth a little bit? So you said that because Grubb is cheap with GPLv3 then we would have to give away our private key? Potentially. First it's not the view of FSF which I believe is upstream for Grubb and they said that anyway if that was the case then you have the possibility to discuss with them to eventually change the license. That's what I read on their website. Yes, I'm aware of the FSF's public position on this and I'm not going to comment any further on that in this session. Why? Yes, basically canonical's best legal advice is that they cannot safely do GPLv3. That's the legal advice they've had and it's what they're going with. The FSF may not necessarily get to choose about this if things end up in court. Yeah, that's fine. So... Yes? Sure. So that's what Abuntu have done. Fedora have gone with a totally signed chain. What should we do in Debian? So I will say just that I... The reason this is a concern for canonical tends to relate to issues that are rather particular to canonical themselves in that canonical does have a business around pre-installation of Abuntu on machines that ship from the OEM that way. I don't think even if everybody agreed with this legal interpretation of the GPLv3 which it's clear that not everybody does I don't know that that would have actually changed anything about the decision Fedora made and I don't necessarily think that should affect what Debian decides to do here because realistically pre-install Debian systems shipped by an OEM are not a real scenario today. Sure. Sorry if I may just ask a perhaps basic question that's already been answered. How much of EFI is currently set in stone with regards to its API? Is there any possibility of revision for the ability to in an automated fashion add additional keys or disabling on initial boots or write once areas of memory so that on initial install the very first time on hardware you could write a set of key or anything like that? So I'm not familiar at all specifically with the standard itself but I'm wondering. Okay, so I mean a lot of that comes down not to the standard but to Microsoft's certification requirements which are going to govern what actually gets shipped as default settings in secure boot. When you talk about some process for initial key loading and whatnot at that point what does that look like? Are you running code automatically from some external media and then doesn't that undermine to a certain degree what secure boot is trying to accomplish if you don't have to get into the machine and configure something in the firmware first? We expect these machines to come from the OEM's secure boot enabled as Microsoft requires. Microsoft's certification requirements do stipulate that it must be possible to disable secure boot and run without secure boot but of course the user has to be able to get into the firmware what would have been called the BIOS but isn't actually a BIOS anymore get into the firmware configuration and make changes there. So it's a usability obstacle for the typical user. There's also a requirement that user must be able to install their own keys. Ooh, a bit of how. Users must be able to install their own keys but exactly how you're going to do that on an EFI system is going to potentially is going to vary hugely from one system to the next. It all depends on how the vendors have implemented things. EFI itself is, dare I say it, quite well specified. It's thousands of pages of documentation about how to do things, what to do. People reading Matthew's blog will feel the pain of actually trying to work out how to make things work rather than what the spec says but there is actually a decent clear spec. The secure boot stuff is much less obvious and again this is one of the problems. So this is where we got the situation where different distros are already looking at different options and different ways of providing secure booting systems is that we don't know exactly what the consequences are going to be if Microsoft disagree with how various people have implemented their own secure boot. This is where we get the choice of signing kernel and modules or not, for example. Right, so actually my best understanding of Microsoft's requirements in fact does not say that they must support adding user provided keys. I mean it's part of the secure boot spec but I don't think that's something that's part of the Microsoft's the Windows 8 certification. It is likely that the ODMs and the firmware manufacturers are going to try to implement that as best they can but it does mean you don't have the necessary technical pressure to ensure they get it right is one of the problems there. Sure. I know you said you weren't going to discuss it and that's fine, you don't need to but I still kind of want to say my piece so the point being first of all canonical can do whatever it wants I actually I run Ubuntu once but mostly I run Debian now but when they say that the court might force somebody in general, anyone, some of your developers to hand over keys I have a big issue with that and I'd like to understand the specific legal reasoning because otherwise as far as I'm concerned it's fun not from you but still and the other point being that a court can order me to or anybody here or there to hand over a key with you because personally speaking what I would say to a court ordering me to do that is you cannot order me to hand over a part of my identity you can rave, you can throw me in jail you can do whatever fuck you want but still Corporations don't tend to take the same view on the questions of civil disobedience of courts the legal advice that we've received is from some top-notch lawyers in the field there are still some questions that we're trying to wrestle with internally about exactly why we've reached this conclusion that seems to be at odds with the FSF's public position but it's not something I would call a case of thud all the people involved do have good intentions I'll vouch for their trustworthiness and there was another point I was going to make there and I've forgotten it so I won't Dumb? Sorry, just a quick additional question so is there any chance of the implementation that Microsoft has of secure boot being revised or adjusted on the basis of public pressure I mean, is this something that we're going to have to from your perspective anyway going to have to work around now or should we be beating down the door and applying direct pressure via OEMs and server manufacturers, et cetera If you know how to apply pressure to an OEM and get them to do what you want please tell me your secret Yeah, please do it So, but as far as you guys know it seems to be set from Microsoft's point of view When you talk about implementation of secure boot first of all Microsoft themselves are not an implementer of secure boot Right, but they have a certification process that they've said that these are the specific bits of secure boot that must have in order to have and it's unlikely that we will get universal coverage if we try to go out to the OEMs individually and say, hey, this is also important and you should do this on all of your systems I don't know what kind of a success rate we can expect there but I don't think we're going to hit 100% The only way to get all the OEMs to do the right thing is to have Microsoft as the company with the purse strings in this particular arrangement to tell them that this is what they have to do and I in fact, so there's a UEFI plug fest the week after this in Redmond and I'm going to be heading up there and talking with some folks you know, face to face, technical level about what our concerns are and whatnot so I'm hoping to be able to talk with them about both canonicals concerns for Ubuntu as well as the Debian community's concerns and you know, lay it out for them what we think is the correct solution but this is obviously no guarantee that Microsoft will change anything We've already got, it's reasonably clear to me anyway that the pressure and the bad press Microsoft received when they first started talking about Secure Boot and about how it was going to be locked down totally actually caused changes or at least clarifications on what they wanted their OEMs to do so of course on x86 they are the monopoly operating system provider so they feel a lot more pressure to actually do what the press basically demand of them is boiled down to of course we still have the problem that on ARM they're very much looking the other way they're not the monopoly provider on ARM so they can do whatever random crap they want So the other thing with respect to the plug fest I don't know how many people in here actually know what a plug fest is or actually the idea of a plug fest is something that Microsoft and Intel and IBM and companies like that have done for a while now which is basically everybody who is implementing to a standard of any sort they bring their toys to the building and test interoperability on them so that's actually the chief purpose of the plug fest is to get people testing interoperability and so that if anything is actually one of the better strategies of getting OEMs and firmware manufacturers to fix their bugs is to actually be able to show them there are bugs so that's actually even that's a large part of why I'm going there as well is I will be poking at them with the Ubuntu secure boot and see what happens Okay, Chibi That's very cool Two separate things from each other first thing is I do not work for Canonical I have not heard their advice and I just want to encourage people to stop trying to pressure that discussion to happen now both because this is a recorded and public session but also because legal advice in general needs to typically stay confidential to the recipient and otherwise there's lots of complications that happen on a separate matter I believe the requirement to allow secure boot to be disabled is for x86 and md64 only it does not apply to ARM and I'm not blaming ARM for this this is a Microsoft thing but I don't know whether Windows 8 certified or I guess Windows RT certified ARM devices are going to become popular or not but whether or not whatever Canonical does Debian currently supports ARM so what are we thinking in that regard for any ARM devices that may ship with this situation Okay, anybody else queuing up on the mic? So what about the large enterprise purchases of PC hardware? I mean there are a lot of big organizations now that have thousands and thousands of Linux servers how do they feel? I mean are they satisfied with the solutions from vendors like Red Hat? I mean I've worked in organizations where they've had over 50% of the machines running Linux and this is going to be a challenge for them and how are they going to respond to this? That's a good question Some of the OEMs are sorry some of the larger customers are going to be big enough to be able to get custom build PCs that have certain configurations obviously but it's then seen against the greater market even the biggest customers may not be able to get to swing things with their suppliers So this is exactly why this is exactly why Red Hat are going down the secure boot thing and going for the signed kernel and modules and everything BDL is shaking his head at me Do we pass the mic forward? Just one other thing and what about government buyers? I mean a foreign government is like non-US buyers of PC hardware going to be comfortable with something that's cryptographically controlled by a foreign corporation Is there any concern from any particular country that has it? Again good question Of course at the moment people happily believe in CAs from all over the world and we know just how secure the CAs are We passed the microphone forward to BDL There's a lot of different things being talked about here and you have to be careful not to conflate too many issues all into one discussion First of all, there are customers in the world who are really really concerned about zero day, bios-oriented virus attacks and that's the real reason that the UEFI community has built the secure boot spec is this is one of their best approaches for how to try and address that and the customers who care about that include people like government agencies who really want to be able to know for sure what the bits are that were booted on the machines that they're operating So for every one of these things that you bring up there's sort of two sides to the issue on one side there's the people who really really want to make sure that they understand what bits are being booted on their machine and that they're not being somehow damaged by malware that's affected the bios but then on the other side there's somebody who says well I don't trust anybody else to make the decision on what the bits running on my machine ought to be So the position that my company is trying to take is one of we want end users to be able to run the bits they want to run but when those users are telling us that it's important to them to be able to know that the bits they want to run are the ones that are actually booting mechanisms like this might be part of providing those sorts of assurances so it isn't so much about trying to have control over what bits run on the machine in the sense of the company tells the user what they can or can't run it's more about if the user says I want to boot Windows 8 it should be Windows 8 and not a molested copy if they want to boot Debian it ought to be Debian if they want to boot Ubuntu it ought to be Ubuntu and so forth and where it gets challenging is that the technical mechanisms for implementing these assurances end up sort of coming down to who has the ability to sign what when and how does that chain of authority work and who can revoke what certificates under what circumstances and those are all really messy ugly details but be careful about assuming first of all that not everybody wants this because there are a lot of people who think this is really really important including people who want to run Linux and in the other direction don't assume that somehow Microsoft is the root of all evil in this case because there's a lot of different motivations coming together to cause people to develop this technology and whether you like it or not at the end of the day it's going to be there and we have to somehow figure out how to deal with it I also the folks that I work with at the company remind me all the time that you need to maintain a mental distinction between Windows 8 and Windows RT and you need to think about sort of that distinction when you're thinking about where the switch is supposed to always exist and where the enable-disable switch is not allowed to exist by the Windows 8 logo requirements Can I have a go as I've got the mic? To answer Don's question about public pressure I think the ARM x86 distinction is really important and somewhat underplayed in a few years time that half your boxes might be ARM boxes and if you can't install anything apart from Windows on them that's going to be a really big deal and as Steve said public pressure made them change the x86 rules there's a small chance public pressure might make them change the ARM rules probably not something to argue if you wanted to argue rather than worry about technicalities It's a combination of public pressure and fear of monopoly litigation again I think the sort of gazillion dollar question here is even if you believe that some huge majority of the devices in the world are going to be running ARM what makes you think that they're going to be shipping with Windows on them? Yeah hopefully it won't be very popular but because of the network effect Windows is popular for the reasons Windows is popular and most people couldn't care less what architecture their system is running I mean that's the point, it's just another computer most of your users can't tell what CPUs inside, they don't care and that's the reason why the technical excuse that they don't have a majority in ARM isn't really valid they have a powerful network effect and it applies to any computer people ship Sure So we've had a lot of discussion about well, do we like secure boot, what are the things around it I'd like to actually focus more on what we in Debian are going to do about it that is the real point of it as I said when I introduced this I'm going to end up doing some of the work on this and I would like some kind of mandate before I get castigated after the fact for being some freedom-hating Microsoft employee or something So one question is is it possible to have another what are the limitations on extra keys we can put on can we say to manufacturers please put our Debian key on is it useful to make a Debian key and try and get people to already have it I'm not sure B-Dale actually wanted the field that because he seemed to be I mean because yes we could ask manufacturers that but I don't expect most of them to give Debian the time of day when we're talking about a scarce resource like NVRAM on a board that they're making with very small margins I don't imagine that manufacturers are going to be interested in having one of the real serious constraints is how much space there is in the firmware to hold a whole pile of keys and so from the beginning the folks planning to implement this stuff have assumed that the right answer is a small very small number of sort of root keys and so I don't think it's reasonable for us to try and operate in a mode where we have to have unique key material in every OEM's machine that doesn't seem like a good approach that leads to this whole sort of question of who do you trust to sign what when and do you have the right terms in the contract under which they're signing things for you to ensure that it doesn't get revoked at weird times and all that I mean a limitation of what's been done so far is that any given binary can only be signed by one key using the secure boot setup which is a major limitation for us probably deliberate it's difficult to tell so of course it won't be possible to have your own key sign the bootloader and still have it functional as a Microsoft signed bootloader that makes it difficult there's been discussion about trying to find some impartial third party Linux foundation or somebody similar basically sign a generic Linux bootloader that we can then all chain from I don't know if there's much traction along that route yet or whether or not we can find someone who is big enough to go around and talk to all the OEM's and get their key included and also trusted enough and I suppose prepared to stand up and be counted and do all that work for us it's a difficult thing in the community so of course I think that's one of the reasons one of the things that as far as I can see why Canonical have gone with the Intel EFI Linux loader in that that one is already signed by the Microsoft key yes? no but binaries have to be signed so we're going with EFI Linux because it's licensed compatible with our understanding and is small, easy to manipulate doesn't have a lot of extra baggage to it it just does one thing and does it well which is it loads on EFI so that's kind of the situation there as far as getting it signed that we do actually have our first binary back from Microsoft signed through that program on EpiLinux bootable provided you're booting on a machine that has those keys so that's the state of play there so I do have running here I don't know if anybody I don't know how much anybody in the room has been actually poking around with EFI James bottomly blogged about and I've wound up on LWN the OVMF kind of QMU virtualized based on Tiano and lets you play around with UEFI in a VM I can demo that running here if there's interest I actually it's not a very polished demo but I can show you basically what the menus look like and things and while I'm setting that up I'll let Steve continue talking about other things so in Debian do we want to do secure boot? I've seen a number of opinions saying that we should just not play expect all the end users to actually disable secure boot if they want to install Debian is that a viable option is it something we would want to do so the microphone I've got the mic the idea of getting a Debian key in somewhere or getting a bootloader that trusts a whole bunch of disco keys I think that's a real problem because we're meant to be allowing people downstream from us to do what we do that's the whole point of Debian is that our derivatives get the same rights so we've got a thing in we don't allow people to do licenses specifically to Debian for free software and saying this key works but you can't make up your own in your bedroom is pretty much the same thing so unless we can make it so that someone can download Debian create their own key using Debian software and somehow have it an equal class to the Debian key I think will have failed so that's why we shouldn't be setting up a list of trusted keys Okay Mic down the front again Quick show of hands from the people here who thinks that we should do secure boot in some way and not just say no Well As in Before everyone answers that Is it possible that in some cases we will have to implement secure boot or wooden boot like is it a possibility that someday an OEM will not implement the disabled secure boot thing So like it's famous that Microsoft doesn't want I'm struggling to hear you sorry I read many places that Microsoft will not allow OEMs to disable secure boot on ARM processors so maybe we have no choice and we have to implement it No Over to me Dale please Microsoft in their Windows 8 logo requirements say that on any x86 based machine the OEM has to provide the switch to turn secure boot off Yes There is no requirement that that switch is easy to find or well labeled or obvious in the BIOS configuration but to meet the Windows 8 logo requirements as they are currently published Microsoft requires that the hardware OEM provide a switch to disable secure boot. Their motivation for this is actually very interesting because of course Windows 8 is the first version of Windows that can work with secure boot and so if you want manufacturers to continue producing hardware that can be used with older versions of Windows you have to have a way to turn off secure boot and so one solution that we can have is that we tell all of our users find the switch turn off secure boot and ignore it but the problem is if you turn that switch off and you have a dual boot machine and you want to use secure boot Windows then you've got that problem of the switch has to be one way for one and one for the other You've also got the situation where potentially especially in bigger corporate environments the standard is going to be that you will not be allowed to turn off secure boot Unless this has changed what I read is that that switch it's mandatory Microsoft says it's mandatory Go on carry on please quick 386 but it shouldn't be there for ARM Correct So in the case of ARM we have to implement it, no choice right? No not at all No because Microsoft doesn't control the market of ARM hardware that comes out and the only requirement is that if you have a piece of ARM hardware that you want to put the Windows logo on then it has to comply with these criteria but anybody who's making ARM devices that are not intended for to ship with Windows on them and there are many out there it's not an issue at all the question is the immediate effect is it makes a Windows phone much less interesting as a device you might want to purchase to hack on but it doesn't immediately mean that you can't get free ARM hardware to hack on So if I read you correctly what happens when the market share of those old versions of Windows decreases to the point where they no longer need the switch feature Exactly We will either have demonstrated that there's enough market share of non-Windows operating systems that the OEMs will naturally want to keep the switch available or we will have all figured out how to make our operating systems boot when the switch is turned on or we'll buy hardware from other vendors Yeah Ian's had his hand up for about five minutes So this question of derivatives that Phil mentions is certainly very important and it's a key thing that we've been trying to do in Debian forever Another thing that we have been trying to do is provide convenient access to non-free stuff as a kind of sideline and it seems to me that this might be a way out of this dilemma to treat signed firmware, signed bootloader whatever it is that we have made with a key that we can't share with anybody as a non-free item and if we do that then we can that is the traditional compromise that we have made to try to support both users and derivatives as best we can Sure, it's an option but at that point of course our standard boot media will never work with secure boot It's a compromise yet How's Steve getting on? Yeah, I can run through a demo here basically there's just some hacky scripts around QMU, KVM at the moment This is the script to launch based on OBMF as the firmware Let's see here if I can point at some So basically you pass it in a device HDB fat colon SP dash keys which is it takes a directory that you have your firmware keys on that you want to load in and makes that show up as a fat file system to under QMU the dash L there tells it where to look for its BIOS those are the key things there the rest is just various switches to QMU to do different things this is being cargo-cultured a bit from some other people that I've been working with on this at the moment Let's see now So there's that script there's also a script to there's a Python expect script which actually configuring a machine for secure you have to go through quite a bit of firmware that happens to back end on to effectively a serial console makes it nice to jam this in at runtime because apparently I don't know if it's supposed to work or not but saving the NVRAM variables so that they're persistent across boots doesn't seem to be working I don't know why I don't know if that's just not implemented in OBMF or whatever so this is a script that I've run each time on boot So let me see here the VM has been started and it's stopped and that seems to actually be a bug of some kind of my setup which I don't understand yet so actually I will trigger it into running by throwing this init machine script at the TTY which will cause it to start doing things and I'm running the script this time just to give it input on the console so that it un-stops which I haven't figured out why that's necessary but here you see it attempting to and then failing to actually find any find anything to boot so it's dropped you to a firmware shell prompt which is kind of DOS shell like in this case we're going to just do an exit and you get this BIOS kind of configuration looking thing pretty simple boot manager it shows you the list of devices it can see escape out of that boot maintenance manager boot options and the device manager is actually where the secure boot is configured so rather than drilling down into this manually although it's various settings of different kinds of keys I'm going to reset here and then run the script again which is going to drive your firmware which is kind of a funny thing to look at and there it goes so now what we get if we hit continue here what that's done is it has loaded into the oh interesting that it failed it's kind of sometimes it likes me and sometimes it doesn't sorry yeah exactly so we will walk the tree manually here FS0 file system zero the fact that it failed and didn't auto boot means I can show you what happens if you try what I've done with that script is it has grabbed out of that directory the local test keys that I've generated for myself and loaded them into the kech and the DB and I think even the platform key so that those are the only keys that this instance of the firmware trusts so now if I try to run bootx64.efi I pick the wrong one so I don't actually get to show you the demo without having to reboot it again anyway so this is actually the signed copy of EpiLinux that I've locally signed the binary with the same key that I also shoved into the firmware and so we've got an EpiLinux that gives you a boot menu and this EpiLinux does no verification of kernels this is it just has it's been patched to have a menu which EpiLinux upstream does not have and it wow really demo syndrome today but it's meant to go ahead and boot off of the disk and everything right we're all very very close to out of time two questions okay right fade on however go and we don't have a mic Joe Joe Joe turn around yell it quickly go yeah unfortunately yeah you're right I haven't been able to ask I'm just to bear with me folks yes you're right you're saying that I haven't told you about the alternatives to boycotting secure boot I was hoping to get there but we really have one out of time this is this is what I'm hoping to work out that's basically what I've just done um I would like us to actually make the decision about do we go do we say no to secure boot do we do something like a bunch to of go with something that has been signed want that will then happily run whatever we tell it to do we go for something like fedora where we end up having to sign everything down the chain do we do something else I'm hoping to to work out with people here what we would like to do but yeah we've been sidetracked Joe microphone to the difference between um strategies seems to also be based on legal advice yes so if we decide that we if in the case that we decide we don't boycott secure boot then before doing anything technical we should get some legal advice shouldn't we yes we should probably get legal advice too um this is going to be something that's going to have to come up right here are the question over here first no I don't know that today we actually support booting in fe mode on the cds on any hardware on ec6 so that's something that regardless of whether Devin decides to implement secure boot fe is the firmware of the future on pc is one way or the other we're not going to have bios boot as an option on these machines once they come out so even if the plan is you have to disable secure boot we've got to implement fe support in in Devin installer and Devin CD or whatever and I'm being told the time's up okay in is suggesting that we should instead of calling it secure boot to be calling it restricted boot that yeah by all means feel free to do that I'm using the name that other people have given it it's not our technology correct it's sbin yes agreed well time's up today thank you for coming I was please continue there is some discussion already started about this on Devin Devel we clearly have more and more to talk about this and not just talk but actually start implementing things I'm hoping to get efi boot working at some level for Weezy even if we don't get secure boot or restricted boot or anything like it working we still have a basic work below that level to do yet thank you for coming folks