*countable infinities only
lists at colorremedies.com
Mon Jun 25 18:37:19 UTC 2012
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.
More information about the devel