From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ad2Dn-0002kE-BK for mharc-grub-devel@gnu.org; Mon, 07 Mar 2016 15:57:43 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad2Dj-0002fc-PO for grub-devel@gnu.org; Mon, 07 Mar 2016 15:57:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad2Dg-0002om-3u for grub-devel@gnu.org; Mon, 07 Mar 2016 15:57:39 -0500 Received: from mail-lb0-x22a.google.com ([2a00:1450:4010:c04::22a]:34934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad2Df-0002og-Nj for grub-devel@gnu.org; Mon, 07 Mar 2016 15:57:36 -0500 Received: by mail-lb0-x22a.google.com with SMTP id bc4so145448314lbc.2 for ; Mon, 07 Mar 2016 12:57:35 -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=n5soeXVJkVJcFNDtcIxMctW+M1EWVRAa8Aginn0pqSY=; b=NnT5y/uVX+k7TDNoGBKhceiR/Dlxus/vsMnTWz/X+f6Ax/wKiWwp5l6+WnnTQIZ1Rc N0CRGJV84SaenbBggXkEMYHhXt//8a/XprHifTSqVblwM2QOvgGr7OKiIkIeMCRX6fab lPHCeCsVftb2ziIm8q7oQIkUyRu81l5kzxJoBpyLnLHdvqJ0YZ78cr1PEE3YplmUF9dA G/lSpVi9hKEh7SgENKlPl1NLzYF57Cr0qn/Y/BSi3E25tvJeOMGakj6UDv+3eKSUpWWT BHF9Tdu5yDGun0tfUt4wk0zqme0YLpKMNloHQ/MbqSESW/mew7UV6WvX8IEufqCoIfsY zx+w== 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=n5soeXVJkVJcFNDtcIxMctW+M1EWVRAa8Aginn0pqSY=; b=ZJOktOcvob3uvZBLTnWinTY5y1Wjn1+F3t9sf+565aK7F4EbOtcQcA/fw1Mqi1Yscq FDltYvchd6bg9KBrbvQkdkhaFlGC6rYsPG2eO2U5Ln02vIU/Bx18IhFNLl8THtpaM/1W iS0zJDRgMyaMBZE3F06avfQe+0Sqzlk6cZtky1m/gU+2Gm3/FFW8ID3NsOGSE8Zg9vt9 mHy5CW6/bhtf+woAZFMNUPBKtHsbZYOu8rapFFF7LSAGBkzVNJBgum0ofWLc6At3y9gb lYbzvLWFXP62qGYhis2w/91jH93zQ8D+gR3BGL6llkgvaTXEBrPLI/sNk9Jutd7T8b01 buLQ== X-Gm-Message-State: AD7BkJKRcpBK50WLvEsm903JiqjQB5qTMeFvS1SEZqVAciRigCWmIa3vc5prO7NWonV1cA== X-Received: by 10.25.41.212 with SMTP id p203mr6279794lfp.48.1457384254666; Mon, 07 Mar 2016 12:57:34 -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 rp10sm3050369lbb.13.2016.03.07.12.57.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 12:57:33 -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> <56DDE5B0.6080002@gmail.com> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <56DDEB3D.4010505@gmail.com> Date: Mon, 7 Mar 2016 23:57:33 +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::22a 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:57:41 -0000 07.03.2016 23:40, Vladimir 'phcoder' Serbinenko пишет: > Le lun. 7 mars 2016 21:33, Andrei Borzenkov 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? > But this is probably 2.03 material > >> >> 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. >> > Again, I feel like it's something for verification framework > >> >> >> >> >