 Right, good morning. It's a pleasure to be here. I hope that this doesn't end up being really awful So my name is Matthew Harris. I work for Nebula. We do private clouds, hardware and magic stuff We're very very buzzword compliant. I'm not going to be talking about that We're going to go back into the past Understanding the dual-boots involves understanding a lot of awful historical detail that is In a lot of ways would possibly be better left in the midst of time, but it said we're going to go back We're going to look at the historical context We're going to try to understand why things are the way we are and I'm going to mostly ignore the technical details If you want to know about technical details of UEFI, I recommend reappraising your life choices Thinking very hard about whether this is something you really want to do and if it is go and search for Probably best one presentation I gave at LCA last year, which would give a technical introduction to UEFI So instead like I said, we're going to be looking at the historical context of secure booth and some discussion of the social issues that were involved in us coming up with solutions for dealing with a Situation where at the worst point it looked like nobody would be able to install Linux on any computers you could buy anymore, which Given that at the time I was working for a company that made money by selling Linux to be installed on computers Would have caused us certain problems Back in 2006 UEFI 2.0 was released now The thing that UEFI 2.0 is that it was the first release of UEFI despite the version number UEFI 2.0 was a follow-up to EFI 1.10 EFI was an Intel specification that Intel controlled Intel developed it to run on IA64 hardware Since IA64 hardware basically never sold They decided that it would be helpful to maybe redevelop this in such a way that could be used on consumer PCs as well and to deal with the fact that We were already starting to see limitations inherent in BIOS. So UEFI EFI turned into UEFI. UEFI is a cross vendor specification If you want to be part of the UEFI development process as a company you can sign up for free to Get certain amounts of access to the specifications and implementation if you want to contribute to it you pay $3,000 a year So by corporate specification level it's really really cheap That should tell you something about how much it usually costs to take part in standards processes So one of the things about UEFI 2.0 was that it describes a method for signing drivers when we talk about signing drivers we mean signing things we mean that we use cryptography to attach a Signature to a file and the signature is made up of a cryptographic hash of the file so you You've seen MD5 sums when you download an ISO and you verify that the file matches the MD5 sum The idea of cryptographic hash is that it's very difficult to make changes and still have the same hash So you take your driver you take a hash of it and then you encrypt that hash with a private key Then something comes along Decrypt the hash using the public key that it has Verifies that it decrypts correctly and verifies that the hash matches the driver Binary and if it does you know it hasn't been modified and you know it was signed by someone who had the private key That corresponds to the public key so UEFI 2.0 does this for drivers and that seems fine Nobody really understands why because it doesn't define any policy for verifying this it doesn't define a way for Distribution of the public keys so that you can verify that the drivers are actually authentic But hey, it's there. It defines how you Embed the signature into the binary It looks awfully like Microsoft's authenticos, which is how Microsoft signed their drivers and that's because it is in fact Microsoft's authenticos It's convenient because we already have software that deals with that Anyway, UEFI 2.2 finally describes a method for image validation. So it's no longer just limited to drivers is also Corresponds to EFI executives one of the big differences between EFI and BIOS is that instead of just writing codes directly onto your disk on EFI systems You can actually run individual applications And so we can find those in the same way as EFI drivers and it also describes methods for Distributing keys which key should be verified and how you can blacklist keys So by 2008 we're at the point where you could invent the UEFI specification And you could actually do something useful with secure boot at this point in the learnings community Those of us who are aware of the UEFI specification, which I think is basically me And a couple of people who work for Dell and some IBM and a couple of people in felt but you know there's a small number of people who are even really aware of you if I as a thing and Our interpretation of this is that this is something that someone doing say an embedded product with UEFI could make use of I find that still seems kind of weird and alien, but sure or Alternatively, it's something that the end user could set up on their machine So they could choose well I want my machine to only boot stuff signed by this company or stuff that I've signed myself We look at the specification. We've seen that the specification allows the user to install keys As long as the system is in ships with keys pre-installed the user can install their keys everything seems fine Let me go through August 2011 now this was the linus con north america in vancouver and It's the 20th anniversary of linux. Well, it wasn't actually 20th anniversary of linux. That was a bit earlier in the year But we have this party People are encouraged to turn up in either black tie or dresses Matthew Wilcox turns up in the dress and there's a certain amount of drinking This is mostly to add a little local color as opposed to any to stick to the relevance but the next day I'm sitting around on a chair in Conference and someone from cononical walks over to me and Matthew and so right that you've just joined the UEFI specification body. Have you seen this email from Microsoft? No, okay If I go and I look at the main list archives and I pull out this Documents the Microsoft have sent to the main list and the document describes the UEFI functionality that Microsoft expect to be present on all Windows 8 client systems when they're sold and one of them is that clients hardware must be UEFI must Support secure boot and must have secure boot enabled by default so out of the box The system will only boot stuff that signed and Most of the point it also says it must carry these Microsoft signing keys It does not require there's any other signing keys be carried. It doesn't the business either, but Out of the box it seems like hardware will potentially only boot windows and Yeah, at the time Seriously discovering that your entire industry is about to vanish while your Bruce Lee hung over is just very unfair The details roughly as I described you generate script graphic cache to the binary you sign the hash for the private key on boot the system verifies that the hash matches the binary and it verifies that the key that was used to sign the hash is the private half of a public key that it trusts and If that isn't true it fails to boot and there's two things they can do there It's neither pop up an error box saying that it fails to Authenticate this binary or alternatively the specification Allowed and fact encourages you to just fall back to the next thing in the boot list So if you attempt to boot off a CD that contains a either unsigned binary or a binary signed with an incorrect key It will instead just boot off hard drive Potentially without even telling you that that's why And there isn't that's fairly straightforward The idea is if your boot loads of compromising you fall back to the next thing the boot list which is with a luck some sort of recovery image The idea is that okay if the system got corrupted you automatically fall back to the recovery image Which then makes everything good for the user again And in Windows 8 this actually happens if you manage to trash your bootloader or one of the other signed components on the next boot It instead boots off the recovery image and then reinstalls large chunks of windows Makes it surprisingly difficult to get rid of windows so what's the justification for this and the answer is that Attacks are getting more sophisticated and there's a little bit of irony here when I talk about attack is getting more sophisticated Because if we go back to the early 80s the original viruses were bootsector viruses They lived in the bootloader area of floppy disks and you put that floppy disk in and it boosted that code and The virus copies itself into memory and then sat there and then whenever you put in another disk It would copy itself onto the other disk as well and it was spread that way and Once we got into operating systems that actually well once we got to the point where people didn't use floppy disks anymore Because seriously how many of you here have never used a floppy disk there must be some of you Yeah, well and just to say I was born in the 80s So I'm not particularly old but really it's the world is terrifying okay, so Attackers instead moved to infecting files directly and then you'd execute a file and it was the virus would be embedded in the file and it would then copy itself into other files and Okay, fine, but then when you execute a file The thing that executes your file is your operating system That means that your operating system has the ability to check the file before Excusing it and scan it and see whether it's got a virus infected So attackers stopped necessarily just infecting files and starts infecting drivers because if you load the driver into the kernel Then it can modify the kernel. So when the kernel is asking is this file okay? The driver can patch that check out and then they move to okay well, we're going to start putting the virus scanning in the kernel so that When you attempt to load a driver we can verify that the driver hasn't been modified so Windows on 64 bit systems has Since this requires that drivers be signed and won't let you load unsigned drivers So that's all well and good But what happens if you modify the kernel directly and the easiest way to modify the kernel directly is to modify the bootloader So when the bootloader loads the kernel it Modifies the kernel and so the kernel again thinks everything's okay, and then if you get really clever If the kernel tries to read the bootloader to verify the bootloader you give it back the correct answer If you can modify the bootloader there is no way for an operating system to verify itself There's no way to avoid Malware that's got in underneath you the only thing you can do is boost off known good media and scan your hard drive some people have got around that by putting the virus in The system BIOS there is a particularly nasty Chinese one which is able to infect some systems Some AMI BIOS is so if you take the hard drive out the new hard drive in the BIOS reinfects your hard drive This is really nasty, and it's becoming increasingly interesting partially because people now do so much more of their financial work on computers And so it's vital that we keep computer cure so that you don't have all your credit card details used to purchase weapons of mass destruction and Also because international ask an argy is increasingly interested in actually controlling people's computers because people now use their computers to build weapons of mass destruction So there's plenty of incentives for attacking that and to the operating system vendors There's plenty of incentive in preventing that so secure boot does have some justification for security It's easy to see it as a control mechanism for disrupting the market in a way unfavorable to us And I'm not going to say that Microsoft wouldn't have been entirely happy if secure boot may have been possible to install Linux But there are justifiable reasons for secure boots as well So what are our options and our options were at this point? It seems fairly limited. We could try drinking. I Already tried that it didn't seem to be working too well for me So instead I thought really maybe I should try drinking again just in case it works better this time And well after that I woke up again, and this time I felt really bad so we consider some of our other options and one of those was we could break RSA encryption and Then we'd be able to just generate a copy of Microsoft's private finding key The problem is that if we were able to do that we'd also have broken HTTPS And so the entire banking industry would be someone's unhappy with us And also there's lots of much smarter people than us already trying to do this and as far as we know failing So that didn't seem like a great opportunity either If we could prove the people's MP then yes, but in that case I would I I'm not to approve the people MP results and me becoming incredibly rich and famous as opposed to Actually, no, I don't want to get me. It's not a priority. So after that I Went back to plan a which was really through this I'm in Canada. I'm just going to drink until Canada goes away so I got back from Canada and Yeah, it'll be a couple of days to really be able to face things like sunlight again and Decided that well, you know We don't appear to have many technical options here And if you can't do something technically then it's more to start thinking about what you can do socially Red Hat's a decently signed company Which means that if I want to get anything done I'm going to need to convince multiple layers of management And that's going to be really tedious and dull and it's going to take forever and nobody's going to care that much Anyway, because right now well two problems first It wasn't an immediate problem and to this was only required for Windows to client Windows 8 client systems Not server systems and we sold many into the server market So while the Linux community in general might be interested in learning from the desktop, which I hear is coming real soon now It wasn't necessarily a red hat priority My general answer to this is when in doubt calls trouble and I have a certain amount of good track record in causing trouble Then September 2011 a couple of things happens The first is that Microsoft had their build conference and one of the things they talked about at their build conference was Secure booth and their requirements for Windows 8. So, you know at the point where Microsoft is talking about it publicly We can talk about it publicly the problem up until this point was that it has only been discussed on the ufi working group mailing list and one of the Conditions of being part of the standards bodies is normally rule one you do not talk about the context of the standards body Rule two is you have internable phone calls Go on forever so I'm going to talk about the Windows 8 requirements and I talked about how right now We potentially have this situation in which computers will be sold that will not boot Linux and While it's possible that you'll be able to disable it There's no requirement that you'll be able to disable it and this could cause problems, but you know right now This isn't happening immediately. There's still some time to work on this We can probably come up with some solutions. We're just not sure what they'll be yet And I end with it's probably not worth panicking yet, but it is worth being concerned which I thought was a sober Description of the current state of things it seems likely that we've probably be able to come some sort of compromise somehow so basically yeah, it was a don't panic and Then this happened So yeah, it's really easy to cause trouble. It's not that you just tell the world that Microsoft's about to take limits away from you and That's kind of like telling the MRA that you're going to take their guns That's slightly less violence, but only slightly The great thing is that you know, I'm just this random Linux developer person who broke this blog post And then two days later Microsoft writer responds Wow Possibly because apparently the entire world's technical press had been calling Microsoft to ask why Microsoft were going to steal Linux and Also, apparently some security agencies were also calling Microsoft asking. What's not that were they doing? How are they going to spy on their people now? so Microsoft were obliged to respond and Pass the Microsoft response was fairly straightforward. The cure boot is a UEFI protocol not a Windows 8 feature I we are implementing a cross vendor standard now this ammunition Apparently, it's usually intended to killing people apparently some people claim that there are other uses for it, but this one in specific is this NATO specification it's a standard for defining ammunition that is supposed to be interoperable between NATO members the idea being that well this way you don't have to have Multiple ammunition supplies for every different NATO member who's engaged in operation and When you're sitting there being shot at I'm sure you're really pleased that you're being shot at with a standard Wouldn't it be awful if it was just some sort of ad hoc thing? Oh damn These three bullets are all from different manufacturers and they're all different sizes Yeah Standards are not necessarily It's not very reassuring that something's a standard if somebody's pointing it at you nothing They said was that Microsoft does not mandate or control the settings on PC firmware the controller enable secure boots from any operating system Other Windows I Microsoft's will say if the system is going to boot Windows It must have this feature boot stuff But you know if you want the system to help with anything else then vendors can do whatever they want or Alternatively, it's not our fault. You know if nobody wants to make stuff to run your toy operating system it's not our fault so Microsoft's response was one of those nice completely technically accurate and Some of this ingenious responses that all companies that are worth anything are really really good at so I don't blame Microsoft with this response It's what I'd have written if I were in their position On the other hand, I have no idea how I'd get into that position. No, please be willing to give me that much responsibility for some reason So after that Again, we go back to reflecting on our options It's around then that I discovered that I'm getting strange liver pains and maybe my original set of plans is not such a great way of solving this problem so we start thinking about Things we can do that don't involve drinking and this is something of new experience for me but we're looking at Trying to come up with multiple Simultaneous strategies to work on that and we're not supposed to just run around screaming We should run around and scream very loudly But we should run around in well-defined ways and we should scream well-defined things in an attempt to continue getting enough attention that people continue putting pressure on Microsoft and also trying to come up with things that we can do that Hardware vendors would be willing to accept We started thinking about the technical options that we had and first was could be convinced vendors to ship a limit key and the idea there would be All the time we're going to ship with a Microsoft key if we have a limit key then we could sign everything with the limit key Okay, and the hardware vendors might even be willing to do that and in a lot of cases the hardware vendors just ship The stuff that the firmware vendors give them and there's only three real firmware vendors that we need to care about So they didn't seem completely implausible But it did seem likely that some number of hardware vendors would not ship a limit key And then you'd have to spend time figuring out which machines could boot Linux and which ones couldn't The other one was who would control a limit key if you have this private key That can be used to sign software and that software can then be booted on the majority of computers You suddenly become a very attractive malware target People who wants to run stuff on other people's computers without them knowing would like your key and we saw this with Stuxnet When it was used to infect a bunch of computers in Iran It took the form part of it took the form of a driver that was loaded into the Windows kernel And that was legitimately signed with a legitimate Windows hardware vendor signing key that had apparently been physically stolen from this company's offices When this key was noticed and blacklisted suddenly such that started being signed with a key from the hardware company Located next door to the first hardware company Now we can make assumptions here like for instance apparently there are companies who have Intelligence agencies who are capable of breaking into buildings and stealing secret keys and Then if one of these keys is compromised you have to revoke the key and then anything signs with that key stops boosting So we needed to find someone who was willing and able to maintain a Linux key and Who could maintain this efficiently securely that if Mossad turned up? That's not really me We couldn't really think of anyone who did seem like a good fit for dealing with Israeli intelligence so Allegedly, I should say I don't think it's ever been proven that it was Israeli intelligence that were responsible for Stuxnet Is anyone here working for Israeli intelligence Okay, so even then if we could securely maintain a Linux key Perhaps we could give an incredible amount of money to an existing security company Maybe we could go to Verisign hand them a large check and say, okay You should sign things with this key and we trust you to keep it securely Who would get access to that so easy to say well red hat canonical Susan so I should have access Should Debian well, okay, maybe Debian should okay. How about Mins or any of these small Specific Linux distributions that are intended to Translate Linux into this one dialect that's only spoken by 15 people in a village that has no roads But these people exist they should be able to run Linux It would be nice if they could continue running Linux, but okay fine We say that the person writing their distribution for 15 people can have their stuff signed How do we determine whether someone is actually writing a list distribution for 15 people in the village or? Alternatively is actually just writing malware to Attack more career or whatever Getting this wrong is a problem and again results in your key being revoked Anthony. Don't stop spooking. There's Basically every single thing that can go wrong results in nobody can boot Linux anymore There's a lot of things that can go wrong. Then what's the licensing issues? if we find something and People can even get source code rebuild it. They can't sign it themselves if that's a licensing problem so ultimately If a limits key is not a great idea How about if we just have a red hat key and then who would get access to the red hat key Well the PR issues of having a red hat key be if red hats went to the hardware vendors and said hey hardware vendors Here's the key that you need for people to be able to install red hat fine red hat continues having a business model What's about Debian and then what's the PR issues of coming up with a solution that means that you can install red hats and not Debian How about if we could get access to Microsoft key? And if we get access to Microsoft key would other people also be able to get access to Microsoft key All the PR issues of working with Microsoft be again. This seems like a slippery slope if Red hats they could get stuff signed by Microsoft, but Mint couldn't That would again seem like red hat being the big lens company is just making life miserable for everybody else So set back how about if we could avoid having pre-installed keys entirely if instead of this idea that the machines Would have to ship with keys installed because we work out a way for when you go to install your offering system you also install a new signing key and if we can define the mechanism for that can we also come up with a A bunch of vendors who are willing to implement this and the answers to that were I'll get to that We could elderly have just given up on Linux and gone back to engage in the pastoral experience And that was pretty tempting at this point So late 2011 red hats canonical are now both fairly active in the UFI specification community With hindsight, we were possibly a few years late to this But you live and learn and we made some proposals require Regarding key management, so the idea is basically that if you put in your CD Don't have a defined mechanism for having a key in a specific location and then it can install a key There were reasonable objections to this based on security and the idea that you if I is not intended to define a policy for user interaction, it's you can't Specify that there must be a button that you can say okay to in UFI and even if you could then which language would it be written in At the time it was irritating to put forward what did we thought was the best compromise proposal and has pushed back with hindsight I This was as far as the hardware vendors and other obvious vendors concerned not really practical and I'm okay with that so Yeah, this is actually some of 2011, but I thought that interrupting my presentation to fix my slides before you saw this slide would be a little rude So pretend that says December 2011 Microsoft update their Windows 8 requirements And first thing they add is that on exit 6 hardware. That's strictly speaking Windows 8 is exit 6 only Arm hardware is Windows RT. So when I say Windows 8 hardware, I'm talking about exit 6 But it must provide the mechanism to disable secure boot and there must be a mechanism for users to install their own keys The precise implementation details of those vary. So when we talk about did we win? Firstly, we're now at a point where we can expect that exit 6 hardware can all have learned to install But there's no stands like way of handling key management on some systems there's a install new key UI option in the firmware and on some systems that requires you to have a binary encoded DER file containing the public key and on other systems it requires it to be a already formatted UEFI variable dump and In some cases these two things are shipped by the same vendor in different product ranges on other machines you have to clear the Key database entirely and then in software you can install new keys and then re-enable secure boot There's no way of handling this for remote deployments Even if you can on your desktop install a new key before you install Linux if you've just wrecked 2000 servers the last thing you want to do is plug a keyboard and mouse into every single one of them so that you can Install a key off a USB stick And it's going to be a documentation nightmare. There was no way that we could tell people Okay, so to install Linux you put the CD in and then you go into the firmware And then you find an option that sounds probably something like secure boot and Then you disable it and if it pops up a big box saying by doing this you're sending your credit card details to the entire universe You should say yeah, it's all good And this didn't seem like a particularly attractive option either but you know at least we weren't dead now We had some options so in February 2012 we head off to Sunnyvale and Sunnyvale is Where and you're based and it's also where we had the UEFI plug fest that spring Sunnyvale makes lax seem like a really happening awesome place and Yeah, spring for you tell you if I plug fest So this is our first opportunity for face-to-face interaction with a lot of these firmware vendors a lot of the hardware vendors and also with Microsoft and we came out this with some level of success. We had we had a Commitment from Microsoft that they would provide open access to the UEFI signing service and that you know as long as the things you sign aren't used to attack Windows and if they are used to attack Windows then The signature might be revoked and then you'll have to produce new media and everything so And this is what we would expect Microsoft to do with their own stuff if it were compromised in some way so This Microsoft can revoke your signature thing. It's fair enough Microsoft are effectively these difficult authorities for this industry because they kind of own this industry and If they're assigned lost control of a key if a very fine customer lost control of a key You would expect very sign to revoke that key even if it caused that customer problems So if a red SSL key was somehow used to attack other systems, we would expect very fine to revoke that key Fair enough So does this mean that everything solved and of course no it doesn't mean that anything solved because otherwise this would be the end of presentation and I would Have to sing and dance for 10 minutes or so to make up the time Licenses Standard at this point Linux bootloader is grub 2 Reason this is that grub 1 was really really awful and the EFI code for it was even worse And anyone that says well you should have just stuck with grub 1 and continue maintaining that is welcome to do so themselves Anyway, gplv3 everybody knows that gplv3 requires you to reach your finding keys One of the things that gplv3 was it had this anti keyboardization clause the idea that gplv3 material must be replaceable by the end user in order to Conforms the license to avoid situations where you sell something that contains free software and they've got the source code But they can't Build anything that will run on that system Turns out that everyone is completely wrong on this point So gplv3 says this You can fall asleep now But basically what this means is if it's possible to replace it you don't need to ship the keys and if the user can if there's mechanism for the user to install their own keys and Then install something signed with their keys. That's fine It doesn't need to be possible for them to build something with your keys as long as there's way of installing their own keys Ultimately, if it's not a user product, you don't need to ship the keys and a user product must be a physical object That's basically intended for home use Software is not to use a product if you sold a computer with learnings pre-installed. This might be a problem If you just sell Linux, it's not so we were fine red hat is not in the hardware industry Come on the court might be a little more upset about this potentially but even though the first option seemed to satisfy that and We went and asked copyright holders to make sure copyright holds are okay with this because when you're talking about whether you're conforming to the license or something there's two main Concerns the first is what was the intent of the copyright holder when they released on this license and also what was the intent of the license author and If you end up in the court case here the opinions of both may be relevant if there's a well-understood license then The opinions of the license holder are probably more important than the opinions of the copyright holders If it's in other circumstances though if the copyright holder made their interpretation of the license clear in advance Then the copyright holds interpretation may be more of them than the license authors Anyway, we went to copyright holders and we went to the license authors and we said okay So this conforms to your understanding the license and this was made easier in the case of grub 2 because they're actually the same people the Free software foundation is the copyright holder of grub 2 and the free software foundation wrote the gpl v3 So we asked and we had a nice conversation. We explained how users we explained what users would have to do in order to be able to run modified versions of software we explained that It would be possible for the user to Install their own keys even if they might have to jump through a few hoops to do so and they would then be able to Sign the object with their keys and they would be able to build modified versions and Sure everybody assumed that that met the license so Speak to your copyright holders speak to your license authors They will give you answers if you don't like the answers then get your lawyers to speak to them again and But we got the answer we wanted the first time so we didn't have to worry about that User control is important user freedoms important We want users to be able to perform key management and we wanted it to be possible for distributions to be able to do things Even without having to go to Microsoft themselves because the Microsoft thing still involves you having to pay $99 to Symantec Symantec then call you up to make sure that you're really you Which seems like a low bar. Yeah, my name is John Malkovich and here's my phone number They call this phone number. Is this John Malkovich? Yes. Good. Thanks identity verified But that's still a reasonable bar and also Symantec won't sell these signing keys if you happen to be living in a Nation that the US government submits them from doing business with So that might have been a problem We came the idea of a machine operating key ends up being mooses and this is Possible because the ui specification allows you to limit Variable access to the pre-boost environment you can create a variable that can only be accessed in the firmware the operating system once running cannot Create or modify these variables and so keys stored in these can't be modified by the running operating system And key installation can then be limited to physically present users because the firmware environments only available to physically present users and The idea here is that you can just pop up an interface that asks users to install keys and Then your bootloader can trust those keys So the bootloader has to be signed by Microsoft but the bootloader can then let you install additional keys and Those additional keys can be used to boot grub or the kernel or whatever So Susan came up with this idea wrote the codes contributed and we merged it into our bootloader This ends up with a reasonable measure of success a button to 1210 was released in October with secure boot support it does not have the Machine operator key support so oven to 1210 doesn't let you install your own keys 30 no for should do for Dora team believe in January lets the user modify their own keys oven to 1204 to now also has support for this Several smaller distributions have picked up on this and is drifting stuff the next version of open Susan should We assume that the next version of rail and so on will Debian. I honestly don't know about I think that's the longer discussion in Debian But we also made available a pre-fun shim and the idea here is that it's a binary bootloader that I wrote that contains the Suzer MLK codes and it's signed by Microsoft But it doesn't have any keys in it So you boot this and by default it will then refuse to boot anything else you boot this It pops up a menu saying that I didn't trust what you just asked me to run and you can then either enroll the hash of the Binary you wanted to run or you can install a key off CD and the advantage of this is that they're Distributions can just take this binary and put this on their install media And then they can generate their own key and they can put the key on there They don't have to deal with Microsoft There's no risk of revocation because this key is not horse massively trusted by hardware so they don't have to worry about it being used as a malware vector and it seems like Possibly a reasonable compromise some of you may disagree That's great. If we have that discussion when I've left Ideally, that'd be lovely As what we have left third-party modules the Lent Foundation Okay, so past your boot is really that you need to have a completely secure stack everything running in kernel space must effectively Detrusted because otherwise you can just turn the kernel into a bootloader The kernel has this feature called K exec that lets the kernel boot Linux It's not too difficult to let this to adapt this so that the kernel will instead boot windows It's completely different. Somebody's already written an implementation to allow the windows kernel to boot Linux This is not a complicated problem And so if your signed kernel will boot unsigned codes Then you've effectively just written a signed bootloader that will boot malware So ideally you have signed kernel modules, but then if you have signed kernel modules You presumably don't give your key to other companies And then how do you deal with the fact that there are a bunch of vendors who want to ship? Signed kernel modules. Sorry. They want to ship kernel modules themselves As far as I was concerned these companies work They should just get their codes into the upstream kernel But apparently many of them are unenthusiastic about that for various reasons so we went to the Lent Foundation, the Lent Foundation often sets up a working group to look at this problem and then not much happens That's an ideal So we came up with a couple of ideas piece of Jones a red hat came up the first basic idea, which is that You could take a vendor. So let's call a Nvidia a made up third-party hardware vendor Could generate a key and they could embed that key within a pecoff binary And then they could give that pecoff binary to Microsoft and Microsoft was through their signing service and they come up with a signed binary and Then the kernel would be able to verify This binary because it would be signed by a key that the kernel trust because the kernel trust saw the keys this renewal system firmware and your system firmware probably contains the Microsoft key and Then it would extract the key from inside this binary and then also trust that key So you'd be able to say well, I trust this key because it is in an object that was signed by a Company whose key I already trust Linus was not particularly enthusiastic about this as anyone who saw the discussion last week be aware Yeah Apparently since we have a kid's track. I'm not actually able to repeat anything that Linus said So Linus's proposal was very straightforward It's you do things before you get this binary sign by Microsoft and then you extract the key from that and you You know that you can trust that key because it's in an object that's fine I'm I'm I was key you take that key out And then you sign it and then you sign it with a key that's kernel trust And that requires a trusted body to perform this role right now We don't have one and it requires a trusted key in the kernel by default and that would be possibly a problem as well But you know, maybe we can get something there. It's not a solved problem. I'll be lent foundation while we were by we I mean Red Hat, Canonical, Suzer and a couple of other contributors were working on producing the shimloader That's now used by the majority of distributions The lent foundation were writing their own bootloader and it was initially intense just be a simple physical present test So you would boot it and it would boot anything as long as you pressed Y first And obviously this wasn't supposed to be an enterprise ready solution But it was intended to be straightforward. It would let people test What they were doing, but it kind of had some scope creeps since then it now supports enrolling hashes. There's a fair amount of Functional overlap with shim the two Can be used for many of the same things, but there's a small functionality the lent foundation loader has that shim doesn't There's some functionality that shim has that the lent foundation loader doesn't the aim is to merge the two The only real problem we had here was that the lent foundation solution was perceived by many people and basically the entire Technology press as being the official solution because the lent foundation has the word Linux in their company name Not coming my name Which has led to a certain mass confusion because there was a lot of oh well now Linux will be able to boot on Windows 8 systems Well, I've been doing that for some time. We shipped a bunch of operating systems that can already do that fine We'll most them this one will go away. There'll be no more confusion Except for all the distributions that then fork it with different functionality Anyway, where'd we end up? So we're now to point where you can install the distributions on systems without the same link to your booth or hands change any other firmware settings So from the original perspective of it should be possible to install Linux without any more difficulty than before we got there If you're a smaller distribution or if you're an end user who wants to build your own kernels You can install and manage your own keys So we've maintained the user freedom that we were concerned about losing and marks of the filter is a trust Which is not perhaps ideal You are guaranteed to be able to define your own user trust if you want on your systems But that involves a certain amount of manual work. You need to remove all the keys You need to enroll your own keys and then all your hardware drivers are still signed by Microsoft So you need to figure out somewhere around that otherwise you don't get any graphics or USB while you're losing So what do we learn? So even commercial distributions can work well together Red Hat, Canonical and through the all cooperated on coming up with a solution that satisfies all their needs Different companies contributed different parts to it, but we ended up with a single code base that everybody's playing on shipping. So awesome We can apparently even work with Microsoft. I Visited them. I'm here. I was not brutally murdered We gained Improve communication with vendors We now have channels of communication between loans vendors and firmware vendors that we didn't have before because we're operating within These standards bodies we now actually see system vendors. We see the firmware vendors We can talk to them when we find issues We know who to talk to they know that there are people in the list community that they can talk to if they find problems That's better Even when things look bad we can come up with solutions. They're not always ideal solutions. There are occasionally trade-offs, but overall Compared to the point less than 18 months ago where we thought that the age of Linux being installable on consumer hardware might be over This is massively better than that things have changed a little Most users are probably not going to notice experienced users are going to be able to maintain their freedoms and We did it without any lawsuits Thank you. I think we've signed for a couple of questions It is that why did we get to the point where once we came up with the solution know the thing to be concerned about the fact Microsoft has done this in the first place and the answer is Well, this is a capitalist society Microsoft have a great deal of money and therefore they get to do what they want The idea that we might want Microsoft to behave in a socially responsible manner sounds awfully like communism to me So right, it's just the narrative is well, okay, if Microsoft to try and use their power to actually put someone out of business That's considered as a bad thing if Microsoft compromise just enough that other people can remain in business Then who cares that's just how people do business I'm not a great fan of that but that's basically how things work this impact DKM Yes, the idea if you want to build if you have secure boot enables And if you want to build your own third-party modules say using DKMS those modules will not load unless they're signed by a trusted key and the only There are two ways around that the first is that the shimloader actually has an option where you can disable Enforcement so you type in the command you reboot the machine the next time shim comes up. It prompts you to enter a Password and you do that and these say disable stupid verification So this is something that would be difficult to fool people into doing And it's something that can't be done automatically and once that's done then Safety verification turns off. You lose the security benefits, but you can sign your own stuff The alternative is that you generate your own key you enroll your own key and some of the patches DKMS such that if there's a key There it'll sign stuff with that key and then everything works Good time for open source Hardware, yeah, seriously deep problem here is if Microsoft didn't dominate the Hardware scene then Microsoft wouldn't be able to do this Long term the only way of preventing this kind of thing happening again is to ensure that Microsoft don't have that level of power Back what can you use KXX right now? No KXX disabled if you're in a security environments if you're using the pack set that we suggest that people use There's ongoing work to come up with solutions for that once I get those Microsoft key well Yeah, I Just think we have to assume that they'll use it responsibly so the specifications act to begin with we had the problem that it was only possible to Find a binary with a single key So if you find your binary with a Microsoft key Then it wouldn't boot on a system that had some alternative roots of trust the specification That's being worked on Hey, I can't really talk about I'm no longer part of the company that is working on this stuff But I also can't really talk about stuff that's going on within the working groups, but There's interest in fixing that problem. So to their red hat still is involved in this We can think of red hat as a faceless corporate entity, but honestly red hat is committed to user freedom I don't think red hat would Stop fighting the user freedom just because I'm not working there anymore I think that would be kind of awful situation other length vendors should also get involved with this I believe the lengths foundation is looking at trying to be involved in the standards process potentially If the lowest foundations able to get involved then perhaps Long-term organizations like free software foundation may be able to I think there's some issues with the UFI bylaws to make it difficult to non-profits to Be in there, but sure So unfortunately, I think we're basically out of time What's our arm hardware the situation is that arm hardware? Sold with Windows RT is required to be locked down and must not have an option to use it to disable this This is a gross affront to user freedom It's also a gross affront to user freedom that the market appears completely happy with because the vast majority of arm hardware Sold comes with locked bootloaders. If you buy an arm phone Typically, you can't install your own operating system until somebody found a way of breaking the bootloader iPads will not run archery software You need to find the entire jail breaking reasoning thing for iPad. That's basically the idea that the iPad can run something that isn't Apple authorized operating system images and Apple's getting increasingly good at preventing that from happening I think the likelihood is that the first generation Windows RT hardware will probably all end up being broken one way or another and there will be Ways for people to install their own stuff on this long term they're going to be right house to prevent that and We shouldn't stand for that But we shouldn't just criticize Microsoft for that Everybody in the industry is doing it and we need to focus on the fact that there's an industry-wide issue that Devices as opposed to computers are Lockable and that's fine with people We need a cultural shift there. We need to target Microsoft that but we also need to target Apple We need to target HTC Sony all these companies that ship devices where you can't modify