Re: Bugs and tasks for 2.02[~rc1]

Le lun. 7 mars 2016 21:57, Andrei Borzenkov <address@hidden> a écrit :

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?

From:	Vladimir 'phcoder' Serbinenko
Subject:	Re: Bugs and tasks for 2.02[~rc1]
Date:	Mon, 07 Mar 2016 21:03:10 +0000