Re: UEFI Secure Boot and Ubuntu - implementation
Hi, Following extensive discussions within Canonical, with our OEM partners, and with various other groups including the FSF, we've decided to use the GPLv3-licensed GRUB 2 boot loader by default on systems with UEFI Secure Boot, to match our behaviour on all other x86 systems. To mitigate the issues with preinstalled systems that we talked about previously, we'll be adding compulsory test cases to ensure that Canonical validates that every system we test has an option to disable secure boot and an option to install user certificates; and we will retain fallback plans involving efilinux in the case of serious error, although we hope we won't need to use them. For Ubuntu 12.10, this will be based on GRUB 2.00; we will also use a number of Fedora's patches against 2.00 that are relevant to secure boot. I've just uploaded most of the necessary packaging, although we still have some details to iron out. For Ubuntu 12.04.2, where 2.00 would be much too big a change to deliver in a standard update, this will either involve a sequence of targeted backports to GRUB 1.99, or a separate package just for this case if that turns out to be infeasible. For more on the discussions leading up to this, see: http://blog.canonical.com/2012/09/20/quetzal-is-taking-flight-update-on-ubuntu-secure-boot-plans/ Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UEFI Secure Boot and Ubuntu - implementation
On 9 July 2012 13:48, Scott Kitterman ubu...@kitterman.com wrote: On Monday, July 02, 2012 01:04:58 PM Alan Bell wrote: On 23/06/12 08:53, Colin Watson wrote: (Not using GRUB 2 is definitely a second-class option as far as we're concerned, so if the FSF ever makes it clear that this wouldn't be a problem for us, I suspect we will gladly reverse our boot loader position.) in the light of the whitepaper the FSF have produced http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web has the position on GRUB 2 changed? I am a bit curious about this paragraph too: No representative from Canonical contacted the FSF about these issues prior to announcing the policy. This is unfortunate because the FSF, in addition to being the primary interpreter of the license in question, is the copyright holder of GRUB 2, the main piece of GPLv3-covered software at issue. I think it's at least indirectly addressed in this interview: http://www.theregister.co.uk/2012/07/06/shuttleworth_responds_uefi/ I'm confused about this. The GPL is a software license, as such it can only be terminated. In such cases the infringing party loses their license to distribute the software. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. The GPLv3 can no more force key disclosure than the GPLv2 can force source code disclosure. Let's assume I'm wrong about that. Under a correctly implemented UEFI system, there are a couple of other ways which an accidentally locked system could be freed by the vendor, without releasing the key exchange key. It could be done by releasing the platform key (which is the only key the vendor would even have), or by producing a signed firmware update. Note that even if the UEFI system is locked to the highest level of security by the vendor, both of these are still possible using the platform key, assuming a correct UEFI implementation. If we are to assume an incorrect UEFI implementation then we are really open to anything. It is quite possible to imagine somebody creating a system with a locked bootloader, signed kernel and modules, no root access for the user, and a package management system which only accepts .debs signed by Canonical's GPG key. If Canonical is responsible for vendor's releases, then under the same logic Canonical would be forced to release their deb signing key if this happened. So will Canonical cease distributing signed debs containing GPLv3 software just in case this happens? -- Alistair Buxton a.j.bux...@gmail.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UEFI Secure Boot and Ubuntu - implementation
On 23/06/12 08:53, Colin Watson wrote: (Not using GRUB 2 is definitely a second-class option as far as we're concerned, so if the FSF ever makes it clear that this wouldn't be a problem for us, I suspect we will gladly reverse our boot loader position.) in the light of the whitepaper the FSF have produced http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web has the position on GRUB 2 changed? I am a bit curious about this paragraph too: No representative from Canonical contacted the FSF about these issues prior to announcing the policy. This is unfortunate because the FSF, in addition to being the primary interpreter of the license in question, is the copyright holder of GRUB 2, the main piece of GPLv3-covered software at issue. Alan. -- I work at http://libertus.co.uk -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UEFI Secure Boot and Ubuntu - implementation
On Monday, July 02, 2012 01:04:58 PM Alan Bell wrote: On 23/06/12 08:53, Colin Watson wrote: (Not using GRUB 2 is definitely a second-class option as far as we're concerned, so if the FSF ever makes it clear that this wouldn't be a problem for us, I suspect we will gladly reverse our boot loader position.) in the light of the whitepaper the FSF have produced http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web has the position on GRUB 2 changed? I am a bit curious about this paragraph too: No representative from Canonical contacted the FSF about these issues prior to announcing the policy. This is unfortunate because the FSF, in addition to being the primary interpreter of the license in question, is the copyright holder of GRUB 2, the main piece of GPLv3-covered software at issue. I think it's at least indirectly addressed in this interview: http://www.theregister.co.uk/2012/07/06/shuttleworth_responds_uefi/ Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UEFI Secure Boot and Ubuntu - implementation
On Sat, 2012-06-23 at 04:21 +0100, Matthew Garrett wrote: Therefore, we will only be requiring authentication of boot loader binaries. Ubuntu will not require signed kernel images or kernel modules. How are you going to prevent your bootloader from being used to launch a trojaned Fedora kernel, for instance? This is the kind of decision that doesn't just affect Ubuntu, it has ramifications for the security model that other distributions use. This makes it impossible to implement any kind of signed userspace unless the user explicitly revokes the Ubuntu bootloader first or uses their own trust chain. Our reading of the UEFI specification and the Windows 8 logo requirements is that Secure Boot is designed to protect early boot only. Protecting the code before ExitBootServices is a worthwhile protection in and of itself and, from a security point of view, something that Secure Boot can solve well. You are right to point out that Ubuntu's current plan is not enough if someone wants a signed userspace. However, extending Secure Boot concepts to perform a fully or partially attested boot is not something that Ubuntu currently wants to pursue. Why? From a security perspective signing the kernel doesn't actually do enough[1] and signing large portions of userspace to solve that deficiency is not an attractive option for many reasons, not least of which is that it reduces the utility of the distribution. As you know, Secure Boot is a very thorny issue and things get complicated quickly. Consider if all FLOSS distributions that want to support secure boot use Fedora's method: * MS signs the 1st stage shim for each distro * the 1st stage verifies the 2nd stage loader (distro-signed) * the 2nd stage verifies the kernel (distro-signed) * the kernel verifies the modules and on up the stack At this point, because all the OS' stage 1 bootloaders (FLOSS and non-FLOSS) are signed by the same authority, we are all are affected by the others. It is clear that if there is a problem with DistroX's boot loader, malware authors will just use DistroX's vulnerable boot loader to attack DistroY and any other systems that don't yet have an update to dbx (including DistroX itself). Obviously this is the purpose of dbx, but dbx is only useful if the individual or OS vendor has a key in KEK such that dbx can be updated. Optimistically speaking, since there isn't a ton of early boot code, in time I expect the bootloader vulnerabilities/bypasses should diminish and people will be looking at the other parts of the system to attack. For example, if there is a problem in DistroY's kernel that affects secure boot (eg, module verification), then a malware author could use DistroY's kernel and bootloader to attack DistroZ and any systems that don't yet have an update to dbx for DistroY's stage 1 bootloader (including DistroY itself). The attack places the old stage 1, old stage 2 and vulnerable kernel and/or modules in place and on reboot, it all verifies. So we need to update the stage 1 bootloader to embed a CSR for every kernel upgrade, get the updated bootloader signed, install the new bootloader and kernel, and update dbx to revoke the old bootloader. The new bootloader can then use the embedded CSR to see if the stage 2 was revoked, and the stage 2 can use an embedded CSR to see if the kernel was revoked (having two stages when you control dbx is not strictly required). This is all doable when the individual/OS vendor controls the key in KEK, but really painful when going through a 3rd party signing authority. It would be a shame if Free Software users had to wait on a 3rd party to sign security updates for their distribution's kernel (indeed, imagine a public critical kernel security update that has to wait days/weeks to be signed before rolling out to users). For these reasons, it seems clear to me that extending Secure Boot to include a partially or fully attested boot by signing the kernel and modules just doesn't seem to work well enough to justify the significant inconvenience to the individual/OS vendor when the individual/OS vendor doesn't have a key in KEK to control dbx. http://lists.fedoraproject.org/pipermail/users/2012-June/419026.html -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UEFI Secure Boot and Ubuntu - implementation
On Mon, Jun 25, 2012 at 03:01:50PM -0500, Jamie Strandboge wrote: At this point, because all the OS' stage 1 bootloaders (FLOSS and non-FLOSS) are signed by the same authority, we are all are affected by the others. It is clear that if there is a problem with DistroX's boot loader, malware authors will just use DistroX's vulnerable boot loader to attack DistroY and any other systems that don't yet have an update to dbx (including DistroX itself). Obviously this is the purpose of dbx, but dbx is only useful if the individual or OS vendor has a key in KEK such that dbx can be updated. Microsoft have volunteered to maintain dbx, so the absence of a KEK isn't a problem - the Microsoft KEK will always be present. In the event that hardware is shipped with a vendor KEK but no Microsoft KEK then the vendor would have to take responsibility, but it seems likely that that'll be a very small corner case. Optimistically speaking, since there isn't a ton of early boot code, in time I expect the bootloader vulnerabilities/bypasses should diminish and people will be looking at the other parts of the system to attack. For example, if there is a problem in DistroY's kernel that affects secure boot (eg, module verification), then a malware author could use DistroY's kernel and bootloader to attack DistroZ and any systems that don't yet have an update to dbx for DistroY's stage 1 bootloader (including DistroY itself). The attack places the old stage 1, old stage 2 and vulnerable kernel and/or modules in place and on reboot, it all verifies. So we need to update the stage 1 bootloader to embed a CSR for every kernel upgrade, get the updated bootloader signed, install the new bootloader and kernel, and update dbx to revoke the old bootloader. The new bootloader can then use the embedded CSR to see if the stage 2 was revoked, and the stage 2 can use an embedded CSR to see if the kernel was revoked (having two stages when you control dbx is not strictly required). This is all doable when the individual/OS vendor controls the key in KEK, but really painful when going through a 3rd party signing authority. It would be a shame if Free Software users had to wait on a 3rd party to sign security updates for their distribution's kernel (indeed, imagine a public critical kernel security update that has to wait days/weeks to be signed before rolling out to users). Again, this isn't a problem. It's trivial to just do this via dbx, as above. My understanding is that you're planning on using the shim loader I've been working on - it supports this functionality. There's no need for a third party to be involved in any part of the process other than providing the revocation update. For these reasons, it seems clear to me that extending Secure Boot to include a partially or fully attested boot by signing the kernel and modules just doesn't seem to work well enough to justify the significant inconvenience to the individual/OS vendor when the individual/OS vendor doesn't have a key in KEK to control dbx. I think you've based this on some misapprehensions. There's no need for any additional significant inconenience for the vendor - they just need to be able to provide exploitable binaries to Microsoft and ship dbx updates via their update mechanism. -- Matthew Garrett | mj...@srcf.ucam.org -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UEFI Secure Boot and Ubuntu - implementation
On Mon, 2012-06-25 at 21:09 +0100, Matthew Garrett wrote: On Mon, Jun 25, 2012 at 03:01:50PM -0500, Jamie Strandboge wrote: At this point, because all the OS' stage 1 bootloaders (FLOSS and non-FLOSS) are signed by the same authority, we are all are affected by the others. It is clear that if there is a problem with DistroX's boot loader, malware authors will just use DistroX's vulnerable boot loader to attack DistroY and any other systems that don't yet have an update to dbx (including DistroX itself). Obviously this is the purpose of dbx, but dbx is only useful if the individual or OS vendor has a key in KEK such that dbx can be updated. Microsoft have volunteered to maintain dbx, so the absence of a KEK isn't a problem - the Microsoft KEK will always be present. In the event that hardware is shipped with a vendor KEK but no Microsoft KEK then the vendor would have to take responsibility, but it seems likely that that'll be a very small corner case. ... Again, this isn't a problem. It's trivial to just do this via dbx, as above. My understanding is that you're planning on using the shim loader I've been working on - it supports this functionality. There's no need for a third party to be involved in any part of the process other than providing the revocation update. I admit I don't have all the most recent details on the shim loader (our Foundations team is handling the implementation details)-- I see just today some commits on adding black/white listing so maybe these are new developments I was unaware that that Microsoft volunteered to maintain dbx. Where was this stated and how are they doing this exactly? How does an individual/OS vendor go about providing the revocation update if Microsoft is maintaining dbx? I was aware that Microsoft would provide dbx updates in their security updates, but on a Fedora or Ubuntu system that doesn't dual-boot, how is the update provided? Based on your comment below, it sounds like the non-Windows OS vendor needs to provide the update: upload the bad bootloader, get a signed-by-MS blob, update dbx via some distro tool. In this scenario, how does Fedora obtain updates to dbx for revoked Ubuntu binaries, and vice-versa (ie, to prevent DistroX bootloader/kernel from being used on DistroY)? This seems like it would get unwieldy in a hurry. For these reasons, it seems clear to me that extending Secure Boot to include a partially or fully attested boot by signing the kernel and modules just doesn't seem to work well enough to justify the significant inconvenience to the individual/OS vendor when the individual/OS vendor doesn't have a key in KEK to control dbx. I think you've based this on some misapprehensions. There's no need for any additional significant inconenience for the vendor - they just need to be able to provide exploitable binaries to Microsoft and ship dbx updates via their update mechanism. I maintain that even if Microsoft makes updates to dbx as painless as possible, we are still relying on their system to work properly and in a timely fashion. If we are signing our kernel, that means we will have to rely on Microsoft for all kernel security updates. While it sounds like dbx maintenance could be (partially) automated by the distribution, there are still potential delays from the 3rd party and the inconvenience for users having to deal with a locked down system by default. Personally, I don't think signing the kernel and modules by default provides enough benefit to warrant the compromises that must be made. Obviously, it is worthwhile to protect early boot, and Ubuntu is working to support using Secure Boot in accordance with the specification. I also think that verifying the kernel, its modules and farther up the stack as part of attested boot is also interesting and something I would like to see supported in Ubuntu, but only as an opt-in for enterprises and interested individuals, not in a general purpose distribution. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UEFI Secure Boot and Ubuntu - implementation
On Mon, Jun 25, 2012 at 04:26:20PM -0500, Jamie Strandboge wrote: I was unaware that that Microsoft volunteered to maintain dbx. Where was this stated and how are they doing this exactly? This was discussed at the last plugfest. How does an individual/OS vendor go about providing the revocation update if Microsoft is maintaining dbx? We're planning on going over the fine details in Redmond next month. I was aware that Microsoft would provide dbx updates in their security updates, but on a Fedora or Ubuntu system that doesn't dual-boot, how is the update provided? Based on your comment below, it sounds like the non-Windows OS vendor needs to provide the update: upload the bad bootloader, get a signed-by-MS blob, update dbx via some distro tool. In this scenario, how does Fedora obtain updates to dbx for revoked Ubuntu binaries, and vice-versa (ie, to prevent DistroX bootloader/kernel from being used on DistroY)? This seems like it would get unwieldy in a hurry. dbx updates will be centralised - a flawed Ubuntu binary is as much a threat to Windows as it is to Linux. Vendors just need to push out any dbx updates via their own update mechanism (so apt, in your case). I maintain that even if Microsoft makes updates to dbx as painless as possible, we are still relying on their system to work properly and in a timely fashion. If we are signing our kernel, that means we will have to rely on Microsoft for all kernel security updates. There's no requirement that dbx updates be simultaneous with kernel updates, and that's actually something you wouldn't want in most cases - you want a grace period in order to avoid any accidental blacklisting before updates with a new key have appeared. While it sounds like dbx maintenance could be (partially) automated by the distribution, there are still potential delays from the 3rd party and the inconvenience for users having to deal with a locked down system by default. Personally, I don't think signing the kernel and modules by default provides enough benefit to warrant the compromises that must be made. Obviously, it is worthwhile to protect early boot, and Ubuntu is working to support using Secure Boot in accordance with the specification. I also think that verifying the kernel, its modules and farther up the stack as part of attested boot is also interesting and something I would like to see supported in Ubuntu, but only as an opt-in for enterprises and interested individuals, not in a general purpose distribution. The benefits of signing purely a bootloader are minimal - bootloaders that load unsigned code will be perfectly willing to set up a secondary UEFI environment and then launch another bootloader that believes it's in a different security context. Even implementing a kexec equivalent that booted the Windows kernel from Linux wouldn't be terribly difficult (ReactOS has most of the necessary code already). It's not obvious that any security is gained at all. -- Matthew Garrett | mj...@srcf.ucam.org -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UEFI Secure Boot and Ubuntu - implementation
On Mon, Jun 25, 2012 at 10:41:17PM +0100, Matthew Garrett wrote: The benefits of signing purely a bootloader are minimal - bootloaders that load unsigned code will be perfectly willing to set up a secondary UEFI environment and then launch another bootloader that believes it's in a different security context. Even implementing a kexec equivalent that booted the Windows kernel from Linux wouldn't be terribly difficult (ReactOS has most of the necessary code already). It's not obvious that any security is gained at all. That's all true. I do wonder, however, if the way Canonical chose is acceptable to Microsoft or not. Because I don't think the general Linux community cares about doubtful security benefits from kernel and module signing. People who want that could use TrustedGRUB[1]. What we do care about is getting Linux to run without much hassle. You seem to be arguing that we want to provide some sort of security to our users while we're at it. But the massive inconvience for all sorts of Linux distributions (like Debian, which might only sign some bunch of unofficial images[2]) doesn't seem to be worth it, IMHO. Kind regards Philipp Kern [1] Yeah, well, I read your point about TPMs not being in mainstream hardware. Let's ignore that. In theory that device was intended to be pushed to the mainstream, just like UEFI. We managed to avoid that, luckily, but you can make use of them, e.g. with Thinkpads. And buy machines that have it. [2] Kernel signing cannot work sensibly with Debian's current infrastructure. I'm aware that Fedora's works differently within RedHat's secure data centers. signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UEFI Secure Boot and Ubuntu - implementation
On Mon, 2012-06-25 at 22:41 +0100, Matthew Garrett wrote: On Mon, Jun 25, 2012 at 04:26:20PM -0500, Jamie Strandboge wrote: I was unaware that that Microsoft volunteered to maintain dbx. Where was this stated and how are they doing this exactly? This was discussed at the last plugfest. How does an individual/OS vendor go about providing the revocation update if Microsoft is maintaining dbx? We're planning on going over the fine details in Redmond next month. I was aware that Microsoft would provide dbx updates in their security updates, but on a Fedora or Ubuntu system that doesn't dual-boot, how is the update provided? Based on your comment below, it sounds like the non-Windows OS vendor needs to provide the update: upload the bad bootloader, get a signed-by-MS blob, update dbx via some distro tool. In this scenario, how does Fedora obtain updates to dbx for revoked Ubuntu binaries, and vice-versa (ie, to prevent DistroX bootloader/kernel from being used on DistroY)? This seems like it would get unwieldy in a hurry. dbx updates will be centralised - a flawed Ubuntu binary is as much a threat to Windows as it is to Linux. Vendors just need to push out any dbx updates via their own update mechanism (so apt, in your case). Understood (and what I was getting at with my question). This is interesting. I'd be curious what protections are in place to keep someone from blacklisting another vendor's binaries (presumably vendors could only blacklist binaries previously signed by themselves). While it sounds like dbx maintenance could be (partially) automated by the distribution, there are still potential delays from the 3rd party and the inconvenience for users having to deal with a locked down system by default. Personally, I don't think signing the kernel and modules by default provides enough benefit to warrant the compromises that must be made. Obviously, it is worthwhile to protect early boot, and Ubuntu is working to support using Secure Boot in accordance with the specification. I also think that verifying the kernel, its modules and farther up the stack as part of attested boot is also interesting and something I would like to see supported in Ubuntu, but only as an opt-in for enterprises and interested individuals, not in a general purpose distribution. The benefits of signing purely a bootloader are minimal - bootloaders that load unsigned code will be perfectly willing to set up a secondary UEFI environment and then launch another bootloader that believes it's in a different security context. Even implementing a kexec equivalent that booted the Windows kernel from Linux wouldn't be terribly difficult (ReactOS has most of the necessary code already). It's not obvious that any security is gained at all. There is benefit to keeping malware out of early boot on its own but I also understand that if someone is doing some form of attested boot that a secure bootloader is the cornerstone for the whole system. Obviously we are not implementing Secure Boot to protect the bootloader alone-- like Fedora, we'd like to be bootable on as many systems as possible. I also appreciate your point on not signing the kernel (which is why I said you are right to point out that Ubuntu's current plan is not enough if someone wants a signed userspace), but a malware writer will happily move on to the first thing that is unsigned that will achieve a similar result. Virtualization[1] easily comes to mind, but I'm sure there are plenty of other methods. Trying to address these other avenues of attack takes us down the path of a completely locked down system, which is onerous to both users and distribution maintainers. [1]http://lists.fedoraproject.org/pipermail/users/2012-June/419026.html -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UEFI Secure Boot and Ubuntu - implementation
On Mon, Jun 25, 2012 at 05:35:34PM -0500, Jamie Strandboge wrote: Understood (and what I was getting at with my question). This is interesting. I'd be curious what protections are in place to keep someone from blacklisting another vendor's binaries (presumably vendors could only blacklist binaries previously signed by themselves). Or demonstrate that a binary is being actively used to attack systems. There is benefit to keeping malware out of early boot on its own I'm not convinced that's true. Anything launched by the bootloader has the same level of access to the hardware as the bootloader. What protection does locking down the bootloader give you over not locking anything down? but I also understand that if someone is doing some form of attested boot that a secure bootloader is the cornerstone for the whole system. Obviously we are not implementing Secure Boot to protect the bootloader alone-- like Fedora, we'd like to be bootable on as many systems as possible. I also appreciate your point on not signing the kernel (which is why I said you are right to point out that Ubuntu's current plan is not enough if someone wants a signed userspace), but a malware writer will happily move on to the first thing that is unsigned that will achieve a similar result. Virtualization[1] easily comes to mind, but I'm sure there are plenty of other methods. Trying to address these other avenues of attack takes us down the path of a completely locked down system, which is onerous to both users and distribution maintainers. Your design decision makes it impossible for anyone signed with the Microsoft key to implement any kind of security beyond the bootloader. This is somewhat incompatible with our plans, and also incompatible with Microsoft's statements about secure boot being something that extends from the bootloader up to the kernel and drivers. I don't deny that it's a rational choice given your security goals, but it has an impact on the designs envisaged by everyone else working on the problem. -- Matthew Garrett | mj...@srcf.ucam.org -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
