On Jun 25, 2012, at 9:25 AM, Gregory Maxwell wrote: > It is being widely reported that Canonical's be signing the kernel, > they won't be requiring signed drivers, and won't be restricting > runtime functionality while securebooted. What is being claimed is > that the only thing they'll be restricting is the bootloader and > they're going to write a new bootloader for this in order to avoid > signing code written by third parties. I'm reading they're going to use a modified Intel efilinux, not writing a new boot loader. And that they will not require either signed kernel or kernel modules. > This seems a bit incongruent with many of the claims made here about > the degree of participation with cryptographic lockdown required and > the importance of it. Yes it does, because the Canonical approach effectively turns UEFI Secure Boot into UEFI Secure Pre-Boot. It is such a minimalist implementation that it's rendered meaningless when a signed pre-boot environment hands off control to an unsigned kernel, the veracity of which cannot be confirmed. The kernel itself could be malware. So what's the point of Secure Pre-Boot? > I feel like the entire discussion has been a bit unfair where people > were repeatedly challenged to offer alternatives when things claimed > to be impossible based on NDAed discussions are, apparently, actually > possible and the remaining weak alternatives were discarded as not > being usable enough. I think for at least 9 months now the idea of a strictly pre-boot implementation of Secure Boot is possible, but meaningless to the point of "WTF, why bother?" with the effort required. It's like building a bridge that's 80% complete, and therefore 100% useless. Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel