Re: Plan of action for Secure Boot support
Perhaps we should find time to hack at DebConf -T On Tue, Aug 19, 2014 at 5:16 PM, Steve McIntyre st...@einval.com wrote: On Tue, Aug 19, 2014 at 01:38:44PM -0700, Ben Hutchings wrote: So far as I know, no progress has been made on the above steps or any alternate approach. Ditto, I've not seen (or done) anything about this. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- :wq -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAO6P2QQQaRyyJ=35Vm=Ux+xst=ln56t5uv0kx8oj3dkwyr6...@mail.gmail.com
Re: Plan of action for Secure Boot support
On Thu, 2014-08-14 at 23:38 +0200, Cyril Brulebois wrote: [...] 1. Colin Watson will prepare dak changes to support upload and subsequent signing of EFI executables. (This is an embedded, not detached, signature.) 2. Steve Langasek will prepare and upload a package of the 'shim' EFI boot loader. This will embed our own set of public keys (corresponding to those used by dak) and can load any other EFI executable signed by one of them. Later, there will be a shim-signed package containing the same executable with a Microsoft signature. (This costs money and takes several days, but shim should require only very infrequent changes.) 3. Colin Watson will update the GRUB package to build a to-be-signed monolithic EFI executable separate from the package. Then he will add a grub-signed package that includes the Debian-signed executable from the archive. This executable would be suitable for use on both removable media and the installed system. 4. The kernel team may also need to upload kernel images for signing and add linux-image-signed packages with the Debian-signed kernel images. This is because some quirks in the kernel should be run before calling ExitBootServices(). could you please tell us whether anything changed during the past year? Is there any chance we could think of having SB in jessie, or should we consider it an unreasonable goal for this release and concentrate on other things? So far as I know, no progress has been made on the above steps or any alternate approach. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Re: Plan of action for Secure Boot support
On Tue, Aug 19, 2014 at 01:38:44PM -0700, Ben Hutchings wrote: So far as I know, no progress has been made on the above steps or any alternate approach. Ditto, I've not seen (or done) anything about this. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819211641.gi7...@einval.com
Re: Plan of action for Secure Boot support
Hi Ben, Ben Hutchings b...@decadent.org.uk (2013-08-13): Colin Watson and Stefano Rivera talked about how Ubuntu had implemented Secure Boot and what they believed were the requirements. Apparently, the Secure Boot spec requires each stage of the boot code to validate signatures only until ExitBootServices() is called. (At this point the firmware makes some parts of its non-volatile configuration inaccessible.) While some users would probably like to be able to 'lock down' the kernel, requiring signed modules and disabling other kernel features that allow code injection, this does not seem to be a requirement for booting on systems that implement Windows 8 logo requirements in the usual way, i.e. that require a Microsoft-signed first stage boot loader. There seemed to be a consensus that we could use an implementation quite similar to Ubuntu's. Some may be concerned that use of a Microsoft signing key results in a non-free binary, but so long as the target machines (amd64 architecture) generally allow installation of alternate public keys this is not so different from the way that APT on a Debian system requires Debian-signed Release files by default. So the plan seems to be: 1. Colin Watson will prepare dak changes to support upload and subsequent signing of EFI executables. (This is an embedded, not detached, signature.) 2. Steve Langasek will prepare and upload a package of the 'shim' EFI boot loader. This will embed our own set of public keys (corresponding to those used by dak) and can load any other EFI executable signed by one of them. Later, there will be a shim-signed package containing the same executable with a Microsoft signature. (This costs money and takes several days, but shim should require only very infrequent changes.) 3. Colin Watson will update the GRUB package to build a to-be-signed monolithic EFI executable separate from the package. Then he will add a grub-signed package that includes the Debian-signed executable from the archive. This executable would be suitable for use on both removable media and the installed system. 4. The kernel team may also need to upload kernel images for signing and add linux-image-signed packages with the Debian-signed kernel images. This is because some quirks in the kernel should be run before calling ExitBootServices(). could you please tell us whether anything changed during the past year? Is there any chance we could think of having SB in jessie, or should we consider it an unreasonable goal for this release and concentrate on other things? Mraw, KiBi. signature.asc Description: Digital signature
Re: Plan of action for Secure Boot support
* Colin Watson: On Wed, Jan 08, 2014 at 08:31:11AM +0100, Florian Weimer wrote: Furthermore, we need to store the keys for all EV certificates (both the certificate used for submission, and the certificate embedded in the shim) in devices that meet at least FIPS 140 Level 2. Such devices that are affordable, support secure, remote operation, and are compatible with free software environments are difficult to find. (But perhaps we can find a DD who agrees to keep the keys in his or her home and manually signs our kernels, using Windows if necessary.) We (Canonical) have been trying to get this requirement made a bit more sane; we keep our SB root certificate split up among a number of shareholders using gfshare, which we believe should be functionally adequate for this. Steve Langasek may know where this sits. Have you had any success in this endeavor? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87siny87ss@mid.deneb.enyo.de
Re: Plan of action for Secure Boot support
On Wed, Jan 08, 2014 at 08:31:11AM +0100, Florian Weimer wrote: Furthermore, we need to store the keys for all EV certificates (both the certificate used for submission, and the certificate embedded in the shim) in devices that meet at least FIPS 140 Level 2. Such devices that are affordable, support secure, remote operation, and are compatible with free software environments are difficult to find. (But perhaps we can find a DD who agrees to keep the keys in his or her home and manually signs our kernels, using Windows if necessary.) We (Canonical) have been trying to get this requirement made a bit more sane; we keep our SB root certificate split up among a number of shareholders using gfshare, which we believe should be functionally adequate for this. Steve Langasek may know where this sits. I wonder why Microsoft no longer wants to sign GPLv3 code (such as GRUB 2). It could be due to plans to make Secure Boot mandatory eventually. Right now, it is possible to comply with the GPLv3 license requirements because users can switch off Secure Boot, either at the BIOS level or through the MokManager loophole. This does not affect us because we rarely ship hardware with Debian pre-installed, and if we do, we can make use of the general GPLv3 opt-out clause. But it would affect some of our users. Not that I'm very impressed with Microsoft's reasoning here, but in practice we wouldn't want to get GRUB signed by Microsoft anyway; their signing process is far too cumbersome for anything but a loader that we try not to change very often. Their guidelines permit chaining to GPLv3 code via shim, so this part of it should not be a problem. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2014010830.ga20...@riva.ucam.org
Re: Plan of action for Secure Boot support
On Wed, 2014-01-08 at 08:31 +0100, Florian Weimer wrote: * Ben Hutchings: However, there is now a blog post from Microsoft that supports what Matthew Garrett has been saying for a while - they may revoke the signature on a boot loader if signature verification is not extended to the kernel, including any mechanism to chain-load another kernel: http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-uefi-ca-signing-policy-updates.aspx (specifically point 5(b)) This implies that when Secure Boot is enabled, only signed kernels and modules can be loaded and other features that allow code injection such as kexec, hibernation and /dev/mem must be disabled. We also need to use an EV certificate in the shim—not just for submission to Microsoft, but also for the certificate that signs GRUB and the kernel (item 6 (a)). The Terms Conditions of existing EV code-signing CAs do not permit a code-signing end-entity certificate to be used for signing another certificate, so we'd directly have to embed the end-entity certificate used to sign GRUB and the kernel into the shim—or we'd have to ship the EV root CA, but that would extend complete trust to that CA. If we embed the end-entity certificate, we need to submit a new shim to Microsoft for signing each time the certificate changes (say, because the previous certificate expired after a year). Presumably actual code signatures never expire (or rather, expiry should not be checked) - as that would mean mandatory upgrades just to keep a machine bootable. CA certificates just need to be updated so they are valid at the point in time they make a signature, right? Furthermore, we need to store the keys for all EV certificates (both the certificate used for submission, and the certificate embedded in the shim) in devices that meet at least FIPS 140 Level 2. Such devices that are affordable, support secure, remote operation, and are compatible with free software environments are difficult to find. (But perhaps we can find a DD who agrees to keep the keys in his or her home and manually signs our kernels, using Windows if necessary.) I'm not sure if we can sign sid kernels because of the requirement to sign production quality code only. testing/unstable is a rolling beta test for the next stable release; I would have thought that was still 'production' in MS's terms. experimental maybe shouldn't be signed. With KVM, we can boot another operating system after executing unauthenticated (userspace) code, so the new policy seems to force us to disable KVM per item 5 (b) (or extended Secure Boot to qemu-kvm, which is practically impossible at present because we do not have a signed userspace). MS can go and stick their collective head in a blender if they expect us to do that. [...] There is also a significant technical limitation: The current shim/grub/kernel combination is totally untested as far as revocation is concerned. Fedora does not blacklist kernels with known root-to-ring-0 escalation vulnerabilities. Well, that would be almost all of them, right? This means that you can just downgrade the kernel to a known-vulnerable version and lose all protections allegedly provided by Secure Boot (as far as the Linux side is concerned). On the other hand, no one really wants to fix this because it would mean that users cannot downgrade kernels anymore to deal with regressions. I expect MS doesn't blacklist their old kernel versions, for exactly the same reason. Or do they? In short, I think it is very hard for us to comply with the new Microsoft guidelines. It is also politically problematic because once we comply, Microsoft could try to claim that mandatory Secure Boot is not locking out anyone (because it's not just Fedora anymore). Because there are no Linux distributions made by anyone but RH, SUSE, Canonical and Debian? We could still do our own thing under a root we control, but then we have to decide if we want to cross-certify everyone else. We should probably continue the discussion on debian-project because it's not just about the kernel or technical issues. Right. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Re: Plan of action for Secure Boot support
* Ben Hutchings: The Terms Conditions of existing EV code-signing CAs do not permit a code-signing end-entity certificate to be used for signing another certificate, so we'd directly have to embed the end-entity certificate used to sign GRUB and the kernel into the shim—or we'd have to ship the EV root CA, but that would extend complete trust to that CA. If we embed the end-entity certificate, we need to submit a new shim to Microsoft for signing each time the certificate changes (say, because the previous certificate expired after a year). Presumably actual code signatures never expire (or rather, expiry should not be checked) - as that would mean mandatory upgrades just to keep a machine bootable. It's not a technical issue. The CA/subscriber agreement doesn't permit making new signatures after the certificate has expired. With KVM, we can boot another operating system after executing unauthenticated (userspace) code, so the new policy seems to force us to disable KVM per item 5 (b) (or extended Secure Boot to qemu-kvm, which is practically impossible at present because we do not have a signed userspace). MS can go and stick their collective head in a blender if they expect us to do that. The usualy argument against disabling KVM is that in order to get KVM support, you need to activate it in the BIOS. I haven't seen enough machines to tell if this is actually true. There is also a significant technical limitation: The current shim/grub/kernel combination is totally untested as far as revocation is concerned. Fedora does not blacklist kernels with known root-to-ring-0 escalation vulnerabilities. Well, that would be almost all of them, right? Yes, it would apply to all but the latest kernel. This means that you can just downgrade the kernel to a known-vulnerable version and lose all protections allegedly provided by Secure Boot (as far as the Linux side is concerned). On the other hand, no one really wants to fix this because it would mean that users cannot downgrade kernels anymore to deal with regressions. I expect MS doesn't blacklist their old kernel versions, for exactly the same reason. Or do they? It's not clear to me what Microsoft's objectives are. Kernel signing might not be required if they only want to save the cost of read-only recovery media. Their installation/recovery kernel does not appear to be equivalent to the real thing, and vulnerabilities in it would not matter as long as the signature checking works (for both kernel and userspace code) and no code with useful vulnerabilities runs before user interaction. There's an expectation nowadays that Secure Boot can protect against careful implants, which is clearly not true on Linux because you could just target the initrd or any of the early boot scripts, without the need for any exploits. Even on Windows, Secure Boot is unlikely to be able to help against unknown implants (or malware injected into the boot process), but it's likely that it enables a reliable recovery path once malware is detectable (and before the malware can, in turn, detect the detection—it's just like Core War). Part of the problem is that Microsoft is extremely tight-lipped about their objectives and policies. As a result, we pick up isolated aspects and assume they reflect an overarching grand plan. But so far, things we once took for granted (like the $99 fee to get started) turned out to be just temporary. In short, I think it is very hard for us to comply with the new Microsoft guidelines. It is also politically problematic because once we comply, Microsoft could try to claim that mandatory Secure Boot is not locking out anyone (because it's not just Fedora anymore). Because there are no Linux distributions made by anyone but RH, SUSE, Canonical and Debian? I might not be up to date on this, but I think only Fedora promoted Secure Boot, and likely did more for the broad acceptance of the concept as such than Microsoft. It's also pretty clear that Microsoft's recent policy changes are partly influenced by Fedora's Secure Boot capabilities. Other distributions either didn't try very hard (no signature checking after ExitBootServices, which is a valid interpretation of the UEFI Secure Boot specification, but not compatible with Microsoft Secure Boot) or explicitly decided against joining the Microsoft Secure Boot ecosystem. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bnzm440t@mid.deneb.enyo.de
Re: Plan of action for Secure Boot support
* Ben Hutchings: However, there is now a blog post from Microsoft that supports what Matthew Garrett has been saying for a while - they may revoke the signature on a boot loader if signature verification is not extended to the kernel, including any mechanism to chain-load another kernel: http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-uefi-ca-signing-policy-updates.aspx (specifically point 5(b)) This implies that when Secure Boot is enabled, only signed kernels and modules can be loaded and other features that allow code injection such as kexec, hibernation and /dev/mem must be disabled. We also need to use an EV certificate in the shim—not just for submission to Microsoft, but also for the certificate that signs GRUB and the kernel (item 6 (a)). The Terms Conditions of existing EV code-signing CAs do not permit a code-signing end-entity certificate to be used for signing another certificate, so we'd directly have to embed the end-entity certificate used to sign GRUB and the kernel into the shim—or we'd have to ship the EV root CA, but that would extend complete trust to that CA. If we embed the end-entity certificate, we need to submit a new shim to Microsoft for signing each time the certificate changes (say, because the previous certificate expired after a year). Furthermore, we need to store the keys for all EV certificates (both the certificate used for submission, and the certificate embedded in the shim) in devices that meet at least FIPS 140 Level 2. Such devices that are affordable, support secure, remote operation, and are compatible with free software environments are difficult to find. (But perhaps we can find a DD who agrees to keep the keys in his or her home and manually signs our kernels, using Windows if necessary.) I'm not sure if we can sign sid kernels because of the requirement to sign production quality code only. With KVM, we can boot another operating system after executing unauthenticated (userspace) code, so the new policy seems to force us to disable KVM per item 5 (b) (or extended Secure Boot to qemu-kvm, which is practically impossible at present because we do not have a signed userspace). Obviously, one can still start a virtualized environment without hardware support, and I don't know what this means for compliance. I wonder why Microsoft no longer wants to sign GPLv3 code (such as GRUB 2). It could be due to plans to make Secure Boot mandatory eventually. Right now, it is possible to comply with the GPLv3 license requirements because users can switch off Secure Boot, either at the BIOS level or through the MokManager loophole. This does not affect us because we rarely ship hardware with Debian pre-installed, and if we do, we can make use of the general GPLv3 opt-out clause. But it would affect some of our users. There is also a significant technical limitation: The current shim/grub/kernel combination is totally untested as far as revocation is concerned. Fedora does not blacklist kernels with known root-to-ring-0 escalation vulnerabilities. This means that you can just downgrade the kernel to a known-vulnerable version and lose all protections allegedly provided by Secure Boot (as far as the Linux side is concerned). On the other hand, no one really wants to fix this because it would mean that users cannot downgrade kernels anymore to deal with regressions. In short, I think it is very hard for us to comply with the new Microsoft guidelines. It is also politically problematic because once we comply, Microsoft could try to claim that mandatory Secure Boot is not locking out anyone (because it's not just Fedora anymore). We could still do our own thing under a root we control, but then we have to decide if we want to cross-certify everyone else. We should probably continue the discussion on debian-project because it's not just about the kernel or technical issues. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878uurexq8@mid.deneb.enyo.de
Re: Plan of action for Secure Boot support
On Tue, 2013-08-13 at 22:54 +0200, Ben Hutchings wrote: [...] Apparently, the Secure Boot spec requires each stage of the boot code to validate signatures only until ExitBootServices() is called. (At this point the firmware makes some parts of its non-volatile configuration inaccessible.) [...] However, there is now a blog post from Microsoft that supports what Matthew Garrett has been saying for a while - they may revoke the signature on a boot loader if signature verification is not extended to the kernel, including any mechanism to chain-load another kernel: http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-uefi-ca-signing-policy-updates.aspx (specifically point 5(b)) This implies that when Secure Boot is enabled, only signed kernels and modules can be loaded and other features that allow code injection such as kexec, hibernation and /dev/mem must be disabled. Or we cross our fingers and hope no-one uses Debian's shim in a Windows boot kit. (There is work on a new kexec interface which could include signature verification. I think there is a theoretical solution for hibernation but I don't think it has been implemented.) Ben. -- Ben Hutchings One of the nice things about standards is that there are so many of them. signature.asc Description: This is a digitally signed message part
Re: Plan of action for Secure Boot support
On Wed, Aug 14, 2013 at 12:30:55AM +0200, Ben Hutchings wrote: Editing of binary packages is icky, so that's not part of the plan. Instead, after dak signs an executable, the package maintainer downloads and copies those into a separate 'source' package, which has a trivial debian/rules. (And of course will generate an appropriate 'Built-Using' header.) This will most likely go via by-hand. So a script on the dak side is needed anyway. Why not do the dummy source package stuff in this script and let dak do all the work semi-automatically? It needs a prepared binary tree in a tar, a list of files to be signed and a DEBIAN dir. Bastian -- Landru! Guide us! -- A Beta 3-oid, The Return of the Archons, stardate 3157.4 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130814094925.ga16...@mail.waldi.eu.org
Plan of action for Secure Boot support
Colin Watson and Stefano Rivera talked about how Ubuntu had implemented Secure Boot and what they believed were the requirements. Apparently, the Secure Boot spec requires each stage of the boot code to validate signatures only until ExitBootServices() is called. (At this point the firmware makes some parts of its non-volatile configuration inaccessible.) While some users would probably like to be able to 'lock down' the kernel, requiring signed modules and disabling other kernel features that allow code injection, this does not seem to be a requirement for booting on systems that implement Windows 8 logo requirements in the usual way, i.e. that require a Microsoft-signed first stage boot loader. There seemed to be a consensus that we could use an implementation quite similar to Ubuntu's. Some may be concerned that use of a Microsoft signing key results in a non-free binary, but so long as the target machines (amd64 architecture) generally allow installation of alternate public keys this is not so different from the way that APT on a Debian system requires Debian-signed Release files by default. So the plan seems to be: 1. Colin Watson will prepare dak changes to support upload and subsequent signing of EFI executables. (This is an embedded, not detached, signature.) 2. Steve Langasek will prepare and upload a package of the 'shim' EFI boot loader. This will embed our own set of public keys (corresponding to those used by dak) and can load any other EFI executable signed by one of them. Later, there will be a shim-signed package containing the same executable with a Microsoft signature. (This costs money and takes several days, but shim should require only very infrequent changes.) 3. Colin Watson will update the GRUB package to build a to-be-signed monolithic EFI executable separate from the package. Then he will add a grub-signed package that includes the Debian-signed executable from the archive. This executable would be suitable for use on both removable media and the installed system. 4. The kernel team may also need to upload kernel images for signing and add linux-image-signed packages with the Debian-signed kernel images. This is because some quirks in the kernel should be run before calling ExitBootServices(). Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: Plan of action for Secure Boot support
On Tue, 2013-08-13 at 22:54 +0200, Ben Hutchings wrote: Colin Watson and Stefano Rivera talked about how Ubuntu had implemented Secure Boot and what they believed were the requirements. [...] Sorry, I'm having name confusion here. Who do I really mean? Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: Plan of action for Secure Boot support
Hi, many thanks for the summary. Ben Hutchings b...@decadent.org.uk (2013-08-13): Colin Watson and Stefano Rivera talked about how Ubuntu had implemented Secure Boot and what they believed were the requirements. Apparently, the Secure Boot spec requires each stage of the boot code to validate signatures only until ExitBootServices() is called. (At this point the firmware makes some parts of its non-volatile configuration inaccessible.) While some users would probably like to be able to 'lock down' the kernel, requiring signed modules and disabling other kernel features that allow code injection, this does not seem to be a requirement for booting on systems that implement Windows 8 logo requirements in the usual way, i.e. that require a Microsoft-signed first stage boot loader. There seemed to be a consensus that we could use an implementation quite similar to Ubuntu's. Some may be concerned that use of a Microsoft signing key results in a non-free binary, but so long as the target machines (amd64 architecture) generally allow installation of alternate public keys this is not so different from the way that APT on a Debian system requires Debian-signed Release files by default. So the plan seems to be: 1. Colin Watson will prepare dak changes to support upload and subsequent signing of EFI executables. (This is an embedded, not detached, signature.) 2. Steve Langasek will prepare and upload a package of the 'shim' EFI boot loader. This will embed our own set of public keys (corresponding to those used by dak) and can load any other EFI executable signed by one of them. Later, there will be a shim-signed package containing the same executable with a Microsoft signature. (This costs money and takes several days, but shim should require only very infrequent changes.) 3. Colin Watson will update the GRUB package to build a to-be-signed monolithic EFI executable separate from the package. Then he will add a grub-signed package that includes the Debian-signed executable from the archive. This executable would be suitable for use on both removable media and the installed system. 4. The kernel team may also need to upload kernel images for signing and add linux-image-signed packages with the Debian-signed kernel images. This is because some quirks in the kernel should be run before calling ExitBootServices(). (Sorry, I'm new to all this) do you mean (1) the regular linux image packages are getting a signature added, and we're using those like we do today, or (2) that we'll have additional linux image packages with the signatures to be used instead of the usual linux image packages when a Secure Boot environment is detected? (or (3) something else…) [As a side yet relevant note: I think there's a general agreement that we aren't going to target putting as many things as possible on a regular CD like we used to do, so a few grub/bootloader things are probably OK; having duplicate linux image packages wouldn't look too nice though.] Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130813213857.ga25...@mraw.org
Re: Plan of action for Secure Boot support
Cyril Brulebois wrote: (Sorry, I'm new to all this) do you mean (1) the regular linux image packages are getting a signature added, and we're using those like we do today, or (2) that we'll have additional linux image packages with the signatures to be used instead of the usual linux image packages when a Secure Boot environment is detected? (or (3) something else…) The secure boot shim is a small bootloader. It's the only part that absolutely needs to be signed by MS, AIUI. It was designed to facilitate distributions in our position. Signed versions are also already available, produced by DD Matthew Garret, though not as Debian packages (perhaps he could be convinced to maintain it?) http://mjg59.dreamwidth.org/20303.html http://www.codon.org.uk/~mjg59/shim-signed/ (Assuming the plan is to use Matthew's shim and not the other one created by IIRC, the Linux Foundation.) -- see shy jo signature.asc Description: Digital signature
Re: Plan of action for Secure Boot support
On Tue, 2013-08-13 at 23:38 +0200, Cyril Brulebois wrote: [...] 4. The kernel team may also need to upload kernel images for signing and add linux-image-signed packages with the Debian-signed kernel images. This is because some quirks in the kernel should be run before calling ExitBootServices(). (Sorry, I'm new to all this) do you mean (1) the regular linux image packages are getting a signature added, and we're using those like we do today, or (2) that we'll have additional linux image packages with the signatures to be used instead of the usual linux image packages when a Secure Boot environment is detected? (or (3) something else…) [...] Signing of EFI executables (aside from MS signature on shim) would be done by dak and would require manual intervention from the FTP team. Editing of binary packages is icky, so that's not part of the plan. Instead, after dak signs an executable, the package maintainer downloads and copies those into a separate 'source' package, which has a trivial debian/rules. (And of course will generate an appropriate 'Built-Using' header.) I suppose GRUB's Linux configuration generator will also need to prefer a signed vmlinuz (whatever name it gets) to the unsigned version. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
