[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bugs and tasks for 2.02[~rc1]
From: |
Andrei Borzenkov |
Subject: |
Re: Bugs and tasks for 2.02[~rc1] |
Date: |
Mon, 7 Mar 2016 23:57:33 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
07.03.2016 23:40, Vladimir 'phcoder' Serbinenko пишет:
> Le lun. 7 mars 2016 21:33, Andrei Borzenkov <address@hidden> a écrit :
>
>> 07.03.2016 22:57, Vladimir 'phcoder' Serbinenko пишет:
>>>>
>>>>>>> I would also appreciate if distros would tell which patches they
>> would
>>>>>>> carry if 2.02 was released as it is now. If some patches are in more
>>>> than 1
>>>>>>> distro we probably need to look into including them.
>>>>>>
>>>>>> Well, I have a bunch of patches that need to be clean up (or even
>>>>>> re-examined), and I've also got the secure-boot branch here:
>>>>>>
>>>>>> https://github.com/vathpela/grub2-fedora/tree/sb
>>>>>>
>>>>>> Which is all the patches distros should be carrying to work with
>> Secure
>>>>>> Boot correctly. This branch is also recently rebased against master,
>>>>>> though I'm not sure what the current thinking is regarding their path
>>>>>> upstream.
>>>>>>
>>>>>
>>>>> Personally I'd rather include support for it. I'm tired of linux vs.
>>>>> linuxefi nightmare, and patches have been in the wild long enough.
>>>>
>>>> So what's the path forward, then? Just make all efi use linuxefi, like
>>>> linux vs linux16? That's pretty close to what I've got already, except
>>>> on arm where it's just "linux" in EFI mode as well. But we could make
>>>> those aliases for the same thing on that platform easily enough. Or do
>>>> you have something else in mind?
>>>
>>> RedHat/Fedora config is too platform-dependent and platform is detected
>> at
>>> mkconfig time rather than at runtime. This is a problem as runtime and
>>> mkconfig can be different. Case that I see often is coreboot failing due
>> to
>>> use of Linux16 (which is a valid protocol for coreboot and is used for
>>> memtest but Linux crashes with it) but other cases exist, like enabling
>> or
>>> disabling of SCM or moving disk to another computer. Can we fix this by
>>> introducing some helper to detect it on runtime? It can either be a
>>> function or a real command
>>>
>>
>> Yes, of course, that was what I actually mean - get rid of special
>> linuxefi and just fold processing into standard linux command. We can
>> simply always call shim protocol if available on EFI; it should return
>> success if secure boot is disabled so should be transparent.
>>
> Can you point to some patch to estimate code size of this change? What if
Here are patches from SUSE tree.
https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-add-linuxefi.patch?expand=1
Note that it duplicates quite a bit of standard linux code. What we
mostly are interested in is grub_linuxefi_secure_validate(). Also it
reloads kernel after verification, which feels wrong, it should keep
verified image in memory.
https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-chainloader.patch?expand=1
This one is likely needed in full.
https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-no-insmod-on-sb.patch?expand=1
Variant of it is needed - we cannot allow arbitrary module loading from
untrusted location.
> shim is not available?
I suppose we need to check whether secure boot is enabled. If yes, we
should fail boot because we cannot verify signature.
> 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.
> boot might. I'd rather make verification framework and make secure boot
> just one client, so module for it can be easily carried by whoever chooses
> to implement it.
How do you decide what verification method to use?
> But this is probably 2.03 material
>
>>
>> What is really a problem (or at least rather more involved) is
>> chainloader. If secure boot is enabled, we effectively need to implement
>> complete relocation of PE binary, bypassing EFI. I remember several
>> interesting bugs in this code in openSUSE :)
>>
>> One more thing is module load. Currently patches disable it and use only
>> modules included in core.img. I think we could relax it and allow module
>> loading from internal memory disk. This will allow distribute signed
>> image as grub-mkstanalone, making available full GRUB functionality.
>>
> Again, I feel like it's something for verification framework
>
>>
>>
>>
>>
>
- Re: Bugs and tasks for 2.02[~rc1], (continued)
Re: Bugs and tasks for 2.02[~rc1], Peter Jones, 2016/03/04
- Re: Bugs and tasks for 2.02[~rc1], Andrei Borzenkov, 2016/03/05
- Re: Bugs and tasks for 2.02[~rc1], Peter Jones, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1], Vladimir 'phcoder' Serbinenko, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1], Andrei Borzenkov, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1], Vladimir 'phcoder' Serbinenko, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1],
Andrei Borzenkov <=
- Re: Bugs and tasks for 2.02[~rc1], Vladimir 'phcoder' Serbinenko, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1], Peter Jones, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1], Andrei Borzenkov, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1], Peter Jones, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1], Vladimir 'phcoder' Serbinenko, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1], Michael Chang, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1], Michael Chang, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1], Andrei Borzenkov, 2016/03/07
- Re: Bugs and tasks for 2.02[~rc1], Matt Fleming, 2016/03/09
- Linux loader EFI handover (was: Bugs and tasks for 2.02[~rc1]), Andrei Borzenkov, 2016/03/09