From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ad9iK-0008Rw-9Y for mharc-grub-devel@gnu.org; Mon, 07 Mar 2016 23:57:44 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33629) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad9iI-0008RS-0r for grub-devel@gnu.org; Mon, 07 Mar 2016 23:57:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad9iE-0005ua-Pq for grub-devel@gnu.org; Mon, 07 Mar 2016 23:57:41 -0500 Received: from mail-lb0-x22c.google.com ([2a00:1450:4010:c04::22c]:33005) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad9iE-0005uW-Cy for grub-devel@gnu.org; Mon, 07 Mar 2016 23:57:38 -0500 Received: by mail-lb0-x22c.google.com with SMTP id k15so4672286lbg.0 for ; Mon, 07 Mar 2016 20:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=TKILMlC9xGoG0IYjUij1iai7MKKM5LCfhbs0yzKZm3U=; b=y299SkLQDrKDonBdGiwKBoe3xR8WtfKpIhyUY4NQV6RTamXi3asp+Gzl69CEfy7v1J rdUZTbB87ReXOUwOzq22aFGfFmGMdjisHUTJse4ZnjM2iJk9H0x5UPQ9zt7AJlYtOMQG qw04+UdH7ZpLqBJXPeiOkau1PtQlI4FOv6vtuLlnmXPDDSv0dFeTLS6hs7dZKnY0VLj3 CDLvfi9movo4CXSngzNoPRHvBGqWOSRvMAeNgOFHumWpALylXPSvanA2X2jMjPGTJbYm 680R/ZCvwie6ADJG6/t4CXMYPv7XEBPbwW1YSZNTraV2/T45+tJ7VMsx9akLXnmertNo BTjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TKILMlC9xGoG0IYjUij1iai7MKKM5LCfhbs0yzKZm3U=; b=JrExtAXTszj4AP6zqiBbUt7LrkYlUaOGQnLIkzVskik1nElTiffLOjImRls379zKhw R8rbbEnjdgYHNp4NWrjBLHcwGyoQlFFz/2tTE6WyF/4rXfEh5XnvQuKInOt5WlVxeonk 95+4YE0zbZxHuxHqI8KLgLK5XQALsBhFc35ZF4FXjTR46X2FQoxwqYhyuyNz83PbFKqn e8tA+12oXsQDAsYFpRkCN67Q66NrCL78G5yGkXnzXSY09B0ANJeFSCBrZbhhX68yUFvk 3iPaX0zE0gSQs3aHOzV3Oa8ptaEcC0IAqTXjge9zAfDY9oHz61L6dkS+cj7AeRSJXf01 VQ6w== X-Gm-Message-State: AD7BkJJ6AkN+SRafRgUg97b2ETWuTaA5wJFNRQsTd4JQfmiWIXtoZrgbrGsVNYjEQ5p+IA== X-Received: by 10.112.140.41 with SMTP id rd9mr9495183lbb.138.1457413057368; Mon, 07 Mar 2016 20:57:37 -0800 (PST) Received: from [192.168.1.42] (ppp109-252-76-159.pppoe.spdop.ru. [109.252.76.159]) by smtp.gmail.com with ESMTPSA id m73sm165457lfm.37.2016.03.07.20.57.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 20:57:36 -0800 (PST) Subject: Re: Bugs and tasks for 2.02[~rc1] To: The development of GNU GRUB , Matt Fleming , Vladimir 'phcoder' Serbinenko , Colin Watson 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> <20160307220132.GI13163@redhat.com> <20160308034010.GA19551@linux-dsax.tai.apac.novell.com> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <56DE5BBF.5050108@gmail.com> Date: Tue, 8 Mar 2016 07:57:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160308034010.GA19551@linux-dsax.tai.apac.novell.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::22c 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: Tue, 08 Mar 2016 04:57:43 -0000 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.