 Hi, so welcome to our afternoon session with Ben Hetchings of our Secure Boot for Debian, and if you have, probably you have any questions, so I have two micros, so raise your hands, I will try to, and to give you the micros, thank you. Well, I don't actually have very much to say, I don't, I won't be able to answer questions, because I don't know a lot of this, I'm just trying to bring people together, so we actually have some sort of a discussion between people who do have plans, who have looked into the various components that are needed to support Secure Boot, and maybe start making some progress on that again. So I don't want to start. Hey, I'm happy to kick off with what we've done in Ubuntu, I'm Colin Watson, I did a proportion of the Secure Boot enablement in Ubuntu. So you have to have a number of elements in the stack, obviously, we started with the things you need in Grubb to be able to boot in Secure Boot mode at all. Obviously you need a signed image, which is not terribly difficult in itself, but you do also need to make sure that you disable module loading. The main constraint in Secure Boot, a signed Secure Boot that's enforced by the spec, is that you must not load unsigned code before Exit Boot Services, which is the firmware code that you make at the end of the, somewhere around the end of the bootloader sequence. So we have a set of patches which we put together with Federa to try to effectively harden Grubb for that. Those work fine, those are in Debian, they're currently turned off by a Debian rules switch, but it's trivial to enable. There's a few other things around that. You have to have corresponding changes to a couple of bits of the installer and you also have to somehow, but you have to arrange for the signing to happen in the right place. So we patched our archive software to accept a custom upload type, which is kind of the same as the way installer images are produced. When it sees an upload of this upload type, then it asks a human for confirmation and if it gets that, then it will sign the upload with an object stored, or the key that's stored on the archive master system, so FTP master. We'd have to port that code to DAC, I guess, but it doesn't, I had a brief look and it doesn't look terribly difficult to do. So the last and most important piece is that you, in practice, while it is possible, and it's very important that it's possible for users to be able to install their own keys on a security system, if you can't do that, then it really is horrendously non-free. However, it's not really very nice for users to have to install their own keys simply in order to install an operating system. It's possible, you can certainly do that, but it means that you have to go through all these very non-standard firmware menus to you often have to type in strings of hexadecimal and all that sort of thing. It's not very much fun. So we slightly reluctantly accepted that we were going to need to sign our images with Microsoft's key. Matthew Garrett has blogged pretty extensively about the reasons for and against this. If you want to go read his blog, warning may contain profanity. And so the effect of this, that we have a package of Matthew Garrett's shim software, which is basically something that you can sign, which contains its own key or its own key ring. If it finds a loader that it trusts, then it will chen through to that. And it also provides services to that loader, which it can use to verify other things like the kernel. So the only signature we had to acquire from Microsoft is one on our package of this shim. So this does mean that any time we rev that shim, we have to go back to Microsoft and say, pretty please, could you sign this new object for us? And so far, we've not had a major problem with that load. It's sometimes a little slow. But fortunately, the shim is revved only very rarely. For Debian, I guess there is the essentially political question of do we think that this signature, which we can't reproduce ourselves, is something that we can put in Debian men. I'm not going to take a position in that, but I expect the project might want to. And the obvious outcomes are whether you have the shim in men and on our default CD images, or whether we say that that's booting on these systems which only have the Microsoft key available, which is going to be a lot of modern systems is something that should be relegated to the non-free CD. I don't know. There are some other things I can bring up, but I've talked for long enough. Does anybody else want to say something? Nobody, really? Okay. There's a question of the signed kernel, which I guess we could go into. Right. Ben and I talked about this a bit over dinner last night. So Ben mentioned, you mentioned in your talk on Sunday that you felt module signing was was an important piece. Yes, although you seem to think that because the spec refers only to code loaded before execute services that that wouldn't be necessary. So it's certainly not necessarily per the letter of the spec. As you say, the spec only requires code that's executed in a basically in a bootloader context to be signed. And the I should point out the, because this kind of misunderstood sometimes that the security model of secure boot is not supposed to be to make it impossible to execute an untrusted operating system somehow. If you want that, that's more likely to be something like trusted boot where you have complete recorded thing through a TPM or complete recorded execution through a TPM. That's not supposed to be what secure bit is for. The point of it is to protect the firmware from abuse by the operating system, which is quite different. So supposedly, you should only have to avoid execution of unsigned code in firmware context, in boot services context. Various people have exhibited things that you can, evil things that you can do with with an unsigned kernel. So I think the the usual attack boils down to something like you can construct a fake UEFI framework that makes Windows think that it's executed within that. Right. So I mean, my position in that is that that amounts to trying to avoid execution of an untrusted operating system, which I think is completely backwards from what the secure bit is intended to achieve. But it's not clear if anybody agrees with me on that. In any case, the so far Ubuntu has only used we permit booting unsigned kernels. We do actually sign our kernels in order that we can jump into them in boot services context to run some quirks code in the EFI stub. And this is, I think the kernel has a couple of bits near the start that allow it to handle a couple of firmware quirks. And we'd like to make use of that. So we do use a signed kernel for that. But if you present the Ubuntu grub with an unsigned kernel, it will happily boot it. It'll just make sure to call exit boot services first, so that you're in runtime services context. I personally feel that for Debian, this kind of thing is very important. Okay, I'm bootloader container, so I like people to be able to install new bootloader as well. But lots more people have to install their own kernel. And I would be pretty uncomfortable with solution that made that impossible for people to do without turning off security features in their firmware. So I personally think it's quite important to be able to do that. But I think we probably also need the ability to do the whole signing stack, so that those people who do control their own key software. Yes, and I think having module signing is probably a useful feature, but it's actually separate from supporting secure boot. It's part of secure boot, but it's separate from the process of enabling the sort of default out of the box situation where you only have the Microsoft key available. Yeah, I think. So far we've had no indication that Microsoft are going to revoke our key for this. I guess more news as it happens because it's not really in our control, but so far indications seem good. So what I would want to know is whether anyone's prepared to do the work in Dac. So just one thing I also wanted to mention is, so as Colin mentioned, there are advantages of actually putting the kernel in sign mode. One thing the new shim lets you do is a machine owner key. So you can actually, with the new shim, you can actually create a local key that you basically tell the shim in set of mode that you trust that key on top of the one that's pre-loaded in it. Then you can use that locally for your own kernel and just sign it, sign them and you can actually boot them in sign mode, even if they're not coming from the archive. You're regarding the signatures of the CDs. I agree that having the ability to ship CDs that people can install without having to install an extra key would be clearly a plus. So I wonder if there is a way to have some sort of detached signature so that we distribute the images from the main event archive without signatures, but we also put somewhere else the signatures so that people can like separate and download the signature or something such. Yeah, the signature is, I can't remember whether, sorry, what did you say? The signatures are embedded in an EFI executable. They are embedded, but there's a tool, part of SB sign tool allows you to detach and reattach the signatures. So it's a separate cuff part, I think, or a separate cuff section. You can't do it. It's a kind of elaborate procedure and, yes, that would be possible. I guess my main concern is making sure that Debian doesn't become something that you have to do all sorts of... I mean, we've made great strides forward in making the installer easier and I'm sort of worried about the situation where people are put off Debian because you have to do this really strange procedure that almost looks like an exploit in order to... Yeah. Why would it be more non-free to include a Microsoft signature than to include a Debian signature? No one else can reproduce the Debian or CAHF signatures. This is true. Debian CD signatures. This is true. I don't think there's a Freeness issue there. I'm proxying other people's concerns, really, and I know Ian Jackson, I think, raised a concern about it. I don't know if he's here. Evidently not, but I can follow up with Ian and see if we can work something out. From my point of view, your point's well taken, but it does mean that the Debian project kind of has less freedom. Yes. It doesn't make any difference to our users, you're right. Personally, I think that as long as we make sure that you can construct something equivalent to yourself, the important thing for me is that it's essentially the... I suppose the GPL V3 puts it well that you must have enough installation information and keys to be able to install your own modified version. And this is essentially under the control of the firmware. I think once the... If somebody distributed a system which only had the Microsoft key did not allow you to install your own key and pre-installed Debian, then I think that person would be in breach of the GPL V3 somewhere. I'm not, obviously, not a lawyer, and I'm not sure I have lawyers backing for that, but that would be my plan reading the GPL. It seems at least to make moral sense. But I think that's up to the distributor of the system. As long as we have systems that do let you to install your own keys, I think as long as we let you make full use of that yourself, then we're not in breach. Yep. But others may disagree. So I did ask, and I think you're starting to answer who's going to work on the... Who would work on the DAC changes? I'm willing to port the stuff I did for Launchpad into DAC. It doesn't look desperately hard. It's 140 lines of Python in Launchpad. Well, plus all of the stuff I did to prepare for it, but I don't think that applies to DAC. Right. Are there any FTP masters here? Are there any FTP masters on IRC? Not at the conference, Steven. Okay. Anyone on IRC? No? No. Okay. Okay. Possibly you and I benched corner Steve McIntyre and Cambridge. What's going on in the CDs? Well, actually, Steve said something to me. In fact, I should corner Steve Lanshake and ask him why the shim isn't in depth. I think that was... You'll probably get a slightly guilty looking response. I don't think there's any particular reason. Probably it's just that it wasn't useful without the Microsoft signature, and we had an outstanding political question about where that was lodged. So I guess the answer is just that we try to upload and see what FTP master says. Yeah. So the idea is it's still a two-stage bill there. Is that right? So certainly for the first stage of that, for the first stage, there's no key involved. Right. So all of our signed objects, we split into two pieces. We have one source package, shim, say, that does the normal unsigned build. We have a second stage sign that downloads the signature from wherever and installs it. Aha, Ian, we had a question for you. I gathered that you had concern about the men's suitability of something like shim signed, the thing in Ubuntu that has a Microsoft signature on the first-stage shim, of course, secure boot. Would you... Is that a correct representation? If so, would you care to elaborate? Right. Sorry to put you in the spot. I don't remember exactly what was proposed, but so I can't really be sure to comment accurately on a real situation, but... Shall I just expand correctly? It's probably easiest if I deal with the hypothetical, which is probably true. I have a problem with the idea that there's a package in main that contains signatures that we can't regenerate. It's okay, in my view, if the signature, if the places where the public key is installed are places that are also controlled by the user. So for example, I don't have a problem with the archive key. Also, the user cannot generate their own signed release files, but on the other hand, if they want to do that, they can just change the public key on their system. So if the user can't change the public key, then there's a problem if they can't do the signature themselves. So I agree that that situation would be a problem at present. All systems that I know of and this is required by Microsoft's current guidelines that contend the Microsoft key for Secure Boot on x86 also have the ability for users to install their own key. Right, and if that's the case, then that's all right, although I understand the situation is a bit more difficult on ARM. The situation is indeed more difficult on ARM and at personally on ARM, I would be rather reluctant to distribute a system that included Grub because I'm not at all clear that that system as a whole would comply with the GPLv3. But I mean ARM is, you know, Windows is an irrelevant on ARM, Linux owns ARM. Right, so indeed, whether anybody complies, whether anybody feels that it's remotely important to comply with the Windows guidelines on ARM unless their Microsoft surface is unclear as yet. I don't know. I guess from my point of view, this is a property of the system that you're installing it on rather than a property that Debian can control. Well, yes, but the thing is that there are certain things where we know that the user is able to change the public key because it's part of the system that we ship. In that case, there's definitely no problem. If we have some good assurance that there's some other means, social means, some legal means, who knows that means that in practice the user will almost always be able to replace that key, then that's probably okay, too. If in practice we expect that the user isn't able to replace the key, then that's a problem and there's a sort of huge gray area in between. Right, so it's essentially a judgment called on how firm we think the Microsoft Windows 8 logo requirements are. I guess that's the thing that we're relying on right now. Also we could see whether the systems that are shipped in practice do in fact have this feature enabled. We could go ahead and make the signatures now and then if we discover that in fact it's a problem, we could stop signing things if we decide that it's not conformant to our principles. That makes sense. Okay, thanks for elaborating. Stefan can probably say more. Have we seen any systems as yet that do not permit the user to install their own key? So no, currently quite a few machines specifically Lenovo don't have the firmware options you said where you can actually type it in, but they all have the option to switch to setup mode and then you can use something like the binary generated by the FE tool package which lets you generate a local PKI on your machine, generates a lockdown.efi binary with that one in there. Then you boot that binary and it essentially creates all of the envirom variable and locks down the system with keys that are not the Microsoft keys. Like my current Lenovo laptop doesn't have the Windows keys on it. It instead has keys that I generated myself. So I can actually test new streams. The other thing I wanted to mention was we forgot to the Windows RT stuff. As far as I know the current requirement on those is that indeed it doesn't let you switch to setup mode at all. It doesn't let you turn off secure boot but it doesn't even let you boot any operating system that currently is signed by Microsoft because it's a different key than the one that we have for UEFA for example for Ubuntu. So they don't sign third party operating systems at all on those. So there is a question with I'm not sure I followed everything you said there. The question is when we say the user needs to be able to change the key we don't necessarily mean that the user can change the key if they spend all afternoon. Right. Right. If there's some kind of relatively straightforward process by which the key can be changed and that I think that's also important. Yeah we actually discussed that with Steve and in theory we can package FE tool which is the current tools to generate those keys so that you can just install the package. It generates a new PKI at that point. Then you can just use SB sign to sign any binary that you want. Right. It sounds like we need to automate this. Right. So it's basically you need to go to get into your BIOS once, set it to setup mode, put into Debian, run that thing. It's going to populate the keys with the ones it just generates and from that point on you can have hooks into I suppose the shim or something to it so that it signs them whenever you install a new binary. So you mentioned earlier the shim machine owner key thing which I think Susie did originally and ended up in shim. So your system doesn't have the Microsoft keys at all on it but if you're prepared to leave the Microsoft keys there does the machine owner key system help? Can you use that to register your own key? Yes except that I was testing the shim so I would have needed the first shim to put the second shim which would have been a bit tricky. Okay that's a specialized kiss that I don't think is going to affect most people. I think most people will be fine essentially always by default going to Windows and Microsoft sign shim and then just put whatever they want by adding keys as a machine owner key in there. Okay so the next step I suppose is the DAC changes and then after that people can work on the grub and shim packages and the city building. So DAC as I say I'm willing to sort out always assuming that FTP master doesn't hit the approach I took. The I can deal with grub I'd like somebody who knows it better deal with shim but I guess Steve or Stefan could do that perhaps. CDM age it's probably best to somebody who knows that better deals with it. I think Steve is probably mostly waiting for the bits in the archive to be ready. Yep so we seem to have something like a plan. That seems roughly coherent. Do you mentioned in your talk on Monday that there was a question of what we do with out of tree modules? Yes if we were to require module signing in some insecure mode or in some as an optional restriction. Right I mean even it never mind necessarily requiring it but if as I say to me the module sign is something that you might wish to enable on a system where you're in control of the keys and you want to make sure that you you know basically a beefed up version of the traditional assist admin practice of disabling module loading if you if you want to avoid certain classes of attacks and it seems reasonable to to require module signing for that but does anybody know how to deal with this for out of tree builds? I had the impression that the key that was used for signing the internal module is ephemeral. There was this Matthew Garrett was working on something to add keys into the kernel where in fact the key for it was going to be a key embedded into a signed EFI blob but the assigned EFI executable because that's what Microsoft signs and then that will be the work delivering just a key into the kernel and Linus was extremely blunt in rejecting this. Along the lines of why should we care about Microsoft's key signing formulas. Exactly yes. Not to mention that as I don't think I mentioned this but I think that the the requirement for the for the signing key that signed SHIM is that it has to be a specifically a 2048 bit RSA key I think that's right. So it has some rather odd limitations. In Ubuntu we arranged to have a separate for it actually to go through a separate master key. So we keep the master key offline and have that signed the actual operational signing key. So at least we have some recourse if in the event that the FTP master system is compromised. I think that would be I think that would be sensible for Debian to do but I don't know who would deal with the master key ascribe arrangements. Do this plane also have all that's needed for DI? I'm sorry could you say that again? I was thinking about DI and Debian live and how does that feel? Right so you need a couple of changes to the letter parts of to the letter parts of DI. You need to change I think it was the kernel installation code and obviously grub installer. They're relatively minor changes they're essentially to install the signed respective signed packages as well. Those are straightforward enough. You also have to obviously arrange to boot things somehow. What I did in what I did in Ubuntu was I had our grub package spit out two different signed objects. One of them is intended for use on normal systems so you basically have to build monolithic grub images analogous to a monolithic kernel that have all of the bits that you think you might need. So I generated one image that contained all of the stuff that you might need to boot a normal system and another image that contains all of the things you might need to boot from removable media. The removable media case in its startup sequence it hunts through all of the devices attached to the system for things that have .desk slash whatever it is in DI. It's not particularly elegant but it seems to get the job done. I think that I know that Steve McIntyre cargo filtered some of the code that I did for EFI images in DI so I think it's probably not very difficult at this point to port the rest of it over. Would that also apply through Deepin Live? Yeah well Dabby in Live is basically a DI in it already with the live installer UDab isn't it? So unless that's changed. Okay so yeah it would apply to them as well. Assuming that they have the only assumption would be that they have the .desk sub directory of their top level images with I think it's info inside it. If they don't then it's trivial to us. And no one else? No? No one else? Okay. Short meeting. We're done. Thanks everyone for coming. Thanks Ben.