On Wed, Mar 06, 2013 at 09:14:27AM -0800, H. Peter Anvin wrote:
> On 03/06/2013 08:55 AM, Peter Jones wrote:
> >
> > So, the problem here seems to be that there's never been widespread
> > compliance with this paragraph, but this patch assumes there has. A
> > brief survey concludes:
>
> No, this patch doesn't assume there is widespread compliance, it is
> trying to address the bits that are not complied with.
Right, but that's basically every x86_64 UEFI machine ever deployed.
[lots trimmed]
> > So it's certainly worth trying to find a better way to check this, but I
> > don't think this patch is it. If we're going to enforce it, we have to
> > make sure that a bootloader that's conforming to what was de facto the
> > standard in 0x020b still works. Otherwise we're just breaking
> > bootloaders for no reason, and that will end poorly.
> >
> > I'd suggest we add a field for the bootloader to make a positive
> > declaration of what version it is using, and only check for the sentinel
> > if the field claims it's doing 0x020c or newer.
>
> Except it doesn't quite work. The problem is that these broken
> bootloaders aren't just a matter of 2.11 vs 2.12, they are implicitly
> assuming that the kernel image itself doesn't happen to contain anything
> harmful in the fields that they don't bother initializing. This would
> be nice and good, except that the demands for the boot sector space is
> fairly high and it gets very cantankerous to turn that into a minefield.
If your only objection is real estate, we can find a way to be clever
about what we do that uses already existing space. For instance, write
back the version number that's supported in the version field, but
byte-swapped, so we can tell it changed (we don't anticipate ever
supporting protocol 0x20b from a kernel that advertises 0xb02, right?)
Just one example - we don't have to do this the exact way I said; we
just need a positive assertion from the bootloader to start doing
enforcement. Versions would be nice, but they're not strictly required.
> In fact, your suggestion is exactly equivalent to the sentinel, except
> you want it to be pre-initialized with 0x20b instead of 0xffff.
No, I want the bootloader to communicate that it understands the boot
protocol revision is 0x020c, so we can /safely/ enter a world where
we're forbidding booting from an older bootloader.
> As such, I don't really know anything better we can do other than:
>
> 1. detect the *properly working* case of the structure properly
> initialized
Which is easy, but it doesn't seem to be anything anybody has ever
shipped on UEFI machines.
> 2. doing legacy bootloader-specific clearing based on the bootloader ID
> if the sentinel triggers -- if you can think of better heuristics
> then that would be good;
This heuristic is "all UEFI bootloaders anybody uses". You can list
them individually, but it's the same as reverting the patch, just with
more code.
> 3. try to get bootloaders switched from case #2 to case #1.
And I'm for that, but I think we should delay enforcement until they've
got a way to express that.
--
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
