From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ad1qr-0001x8-7b for mharc-grub-devel@gnu.org; Mon, 07 Mar 2016 15:34:01 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38502) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad1qo-0001vt-HY for grub-devel@gnu.org; Mon, 07 Mar 2016 15:33:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad1ql-0005gl-Bq for grub-devel@gnu.org; Mon, 07 Mar 2016 15:33:58 -0500 Received: from mail-lb0-x233.google.com ([2a00:1450:4010:c04::233]:35887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad1ql-0005gY-3r for grub-devel@gnu.org; Mon, 07 Mar 2016 15:33:55 -0500 Received: by mail-lb0-x233.google.com with SMTP id x1so144816946lbj.3 for ; Mon, 07 Mar 2016 12:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=hLTy5Otz0sf0zEKQAzqPA7co1gmfhh3l8bPWyHt1ldw=; b=ySpNkYhJSiWyQ6LB+AY6pcR/danYWrCkUjYUtGoidXYkANsLmmvhQxK45Ux2vZq/UQ 0/7yvCXIc8YedEzlH6F0cw+3izWjOnjt409L92Av+/gt+9XtsVMxRzhMKl9TkOimxwbT YPT1RoHfUicsoL7bxr1GqNIwXvDxV9UZfJIHqdCXeeWk6p6N47YlMep/8wvX+5h4WA8k 48fxsJD8N9xFD/QUoNWdTWwphPd80his3Ydn03qabZlmhWmYjaVVN+kGH58MnnoTfOZm VlWv0hO/ShfKYtFGDIRNPNm1utVI/ofzZ9W+bClMnBD6LyDk+VL4ROH1LIZJluEssU0T NglQ== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hLTy5Otz0sf0zEKQAzqPA7co1gmfhh3l8bPWyHt1ldw=; b=SYxjC89O/PMCoK4gh6BJwOIdk0P3ntXvcljuV9v7q7+nXRAP1F7K//y6k4zpkjLpFn haDGL276DNvr3LXU1AR8iO3lG9knqWsGzLnq1IhaZY2o6pZD0IeXOYbHYPEcYhOPtn8G d1d+LaLKneGGjg1bhLO2v8r/805ZGPQN+MUNz4hnY/20CghluVpgCzLAsuvZYa36tgiJ hGFc+rhy5h5JpG8TYyXcp7Z5BkS7dgKOD+sPLGkR4Y/V/0MmZDjbdg3hzFB7xyMmOQy4 RHIYOoDABPC8TFF23UVn5qJs7FrbeRW7USHhLzkfZmA7rR/ksQ6vmvR9MZhcTthiexGF ikGw== X-Gm-Message-State: AD7BkJLZO8zviHqBKnyhhnmrjyBXYmbQEd40PVE3PiCG/Ijzt+gZT7bx6IEkvezBwRZ9Yw== X-Received: by 10.112.173.202 with SMTP id bm10mr8444621lbc.17.1457382834208; Mon, 07 Mar 2016 12:33:54 -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 vq10sm2991214lbb.14.2016.03.07.12.33.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 12:33:53 -0800 (PST) Subject: Re: Bugs and tasks for 2.02[~rc1] To: Vladimir 'phcoder' Serbinenko , Peter Jones References: <20160304200641.GC27106@redhat.com> <56DA9AE8.3010006@gmail.com> <20160307190016.GA13163@redhat.com> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <56DDE5B0.6080002@gmail.com> Date: Mon, 7 Mar 2016 23:33:52 +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: 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::233 Cc: The development of GRUB 2 , Colin Watson 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 20:33:59 -0000 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. 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.