From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ad3Do-0000zz-29 for mharc-grub-devel@gnu.org; Mon, 07 Mar 2016 17:01:48 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad3Dl-0000vp-6E for grub-devel@gnu.org; Mon, 07 Mar 2016 17:01:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad3Di-0005Fb-0a for grub-devel@gnu.org; Mon, 07 Mar 2016 17:01:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad3Dh-0005F4-S6 for grub-devel@gnu.org; Mon, 07 Mar 2016 17:01:41 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 440246315B; Mon, 7 Mar 2016 22:01:41 +0000 (UTC) Received: from redhat.com (ovpn-112-81.phx2.redhat.com [10.3.112.81]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u27M1X9A016128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Mar 2016 17:01:38 -0500 Date: Mon, 7 Mar 2016 17:01:33 -0500 From: Peter Jones To: Andrei Borzenkov Subject: Re: Bugs and tasks for 2.02[~rc1] Message-ID: <20160307220132.GI13163@redhat.com> References: <20160304200641.GC27106@redhat.com> <56DA9AE8.3010006@gmail.com> <20160307190016.GA13163@redhat.com> <56DDE5B0.6080002@gmail.com> <56DDEB3D.4010505@gmail.com> <20160307211958.GF13163@redhat.com> <56DDF2AA.3010504@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56DDF2AA.3010504@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 07 Mar 2016 22:01:41 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Cc: Matt Fleming , 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 22:01:46 -0000 On Tue, Mar 08, 2016 at 12:29:14AM +0300, Andrei Borzenkov wrote: > 08.03.2016 00:20, Peter Jones =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > 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. Acceptin= g 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. > >=20 > > No, they're doing it because that is the supported entry point for EF= I > > 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 sta= rt > > again. I've Cc'd Matt Fleming, the upstream kernel EFI maintainer, > > because I'm sure he's going to agree with me. >=20 > 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. 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 - 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. - 64-bit kernel on 32-bit platform like Baytrail can't work - some machines we won't get the virtual address map right and e.g. UEFI variables just won't work It goes on like this. --=20 Peter