From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ad2Qn-0002xN-SH for mharc-grub-devel@gnu.org; Mon, 07 Mar 2016 16:11:09 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad2Ql-0002uw-FK for grub-devel@gnu.org; Mon, 07 Mar 2016 16:11:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad2Qg-0007UJ-Kd for grub-devel@gnu.org; Mon, 07 Mar 2016 16:11:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad2Qg-0007TY-EP for grub-devel@gnu.org; Mon, 07 Mar 2016 16:11:02 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id ADBC2C00F21F; Mon, 7 Mar 2016 21:11:01 +0000 (UTC) Received: from redhat.com (ovpn-112-81.phx2.redhat.com [10.3.112.81]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u27LAsWb004879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Mar 2016 16:10:59 -0500 Date: Mon, 7 Mar 2016 16:10:54 -0500 From: Peter Jones To: Andrei Borzenkov Subject: Re: Bugs and tasks for 2.02[~rc1] Message-ID: <20160307211053.GD13163@redhat.com> References: <20160304200641.GC27106@redhat.com> <56DA9AE8.3010006@gmail.com> <20160307190016.GA13163@redhat.com> <56DDE5B0.6080002@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56DDE5B0.6080002@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: Vladimir 'phcoder' Serbinenko , Colin Watson , The development of GRUB 2 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 21:11:08 -0000 On Mon, Mar 07, 2016 at 11:33:52PM +0300, Andrei Borzenkov wrote: > 07.03.2016 22:57, Vladimir 'phcoder' Serbinenko =D0=BF=D0=B8=D1=88=D0=B5= =D1=82: > >> > >>>>> 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 m= ore > >> 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 S= ecure > >>>> Boot correctly. This branch is also recently rebased against mast= er, > >>>> though I'm not sure what the current thinking is regarding their p= ath > >>>> 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, l= ike > >> linux vs linux16? That's pretty close to what I've got already, exc= ept > >> on arm where it's just "linux" in EFI mode as well. But we could ma= ke > >> those aliases for the same thing on that platform easily enough. Or= do > >> you have something else in mind? > >=20 > > RedHat/Fedora config is too platform-dependent and platform is detect= ed at > > mkconfig time rather than at runtime. This is a problem as runtime an= d > > 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 fo= r > > memtest but Linux crashes with it) but other cases exist, like enabli= ng 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 > >=20 >=20 > 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. >=20 > What is really a problem (or at least rather more involved) is > chainloader. If secure boot is enabled, we effectively need to implemen= t > complete relocation of PE binary, bypassing EFI. I remember several > interesting bugs in this code in openSUSE :) We've already got something like that (I think derived from the SuSE patch) here: https://github.com/vathpela/grub2-fedora/commit/4ea532fc9f8af1b1b23f424e3= 205c5eebfa8f877 I think at this point it seems to generally work. Note that we're bypassing EFI for loading, but we're still calling into shim for the verification, so there's not a validation loophole here. > One more thing is module load. Currently patches disable it and use onl= y > modules included in core.img. I think we could relax it and allow modul= e > loading from internal memory disk. This will allow distribute signed > image as grub-mkstanalone, making available full GRUB functionality. I'm not seeing what this accomplishes. We don't have major limitations on e.g. bootloader size on these platforms, so linking in the modules we're comfortable supporting the first time is not a big deal. Maybe I'm just missing your point though? --=20 Peter