Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov <arvidjaar@gmail.com>]

08.03.2016 06:40, Michael Chang пишет:
> On Mon, Mar 07, 2016 at 05:01:33PM -0500, Peter Jones wrote:
>> On Tue, Mar 08, 2016 at 12:29:14AM +0300, Andrei Borzenkov wrote:
>>> 08.03.2016 00:20, Peter Jones пишет:
>>>> On Mon, Mar 07, 2016 at 11:57:33PM +0300, Andrei Borzenkov wrote:
>>>>>
>>>>>> How big part of it is related to secure boot? Just
>>>>>> changing Linux boot protocol doesn't need FSF involvement. Accepting secure
>>>>>
>>>>> Patches currently use EFI stub to launch kernel but I think this is done
>>>>> simply to make code easier. We can continue to use the same load
>>>>> protocol as before, just add image verification.
>>>>
>>>> No, they're doing it because that is the supported entry point for EFI
>>>> in Linux.  We do not want EFI machines using other entry points.  It
>>>> worked out terribly when we used to do this, and we don't want to start
>>>> again.  I've Cc'd Matt Fleming, the upstream kernel EFI maintainer,
>>>> because I'm sure he's going to agree with me.
>>>
>>> So you mean that linux loader is currently broken on EFI?
>>
>> None of the 3 OSes we produce ever uses it.  I don't know about what
>> other distros ship, but a lot of them are using the secure boot code by
>> default in all cases, so they're also going through the EFI stub.
>>

SUSE allows switching off secure boot in YaST, this is relatively
popular advice to users to work around some problems and quite a lot of
users simply do not want to use SB at all (judging by forum posts). So
it gets at least some use in the wild.

>> My expectation is that on many systems it does work, but there are a lot
>> of corner cases where things are not quite right.  In those cases you'll
>> see problems like:
>>
>> - less total memory available than expected due to e820 vs efi memory
>>   map issues

Do you have pointers to real-life examples?

>> - the very real issue recently where grub set the type incorrectly on
>>   some memory map entries, resulting in NVDIMMs winding up being marked
>>   as normal allocatable memory.

Fixed in beta3.

>> - 64-bit kernel on 32-bit platform like Baytrail can't work

Do you mean "32 bit EFI"? If yes, why is it a problem?

>> - some machines we won't get the virtual address map right and e.g. UEFI
>>   variables just won't work
>>

This sounds like bug in GRUB that needs fixing anyway.

>> It goes on like this.
> 
> On the other hand, other grub2 functions like gfxpayload is broken with
> linuxefi, as efi stub would set screen_info from scratch by gop protocol
> and also linuxefi doesn't initialize it at all (as it seems not relevant
> for the efi stub).
> 
> I think the switch to efi stub has to consider the existing grub.cfg
> could still service without changes and function regression, or we will
> end up in trouble of maintaining the config that is in continously
> running, espeically for those not created by grub-mkconfig. 
> 

Yes, any implementation should reuse as much of existing loader code as
possible and only change handover method.