From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A164BC2BA83 for ; Fri, 7 Feb 2020 18:31:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 73B1221741 for ; Fri, 7 Feb 2020 18:31:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="c/KE7MDX" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727012AbgBGSbs (ORCPT ); Fri, 7 Feb 2020 13:31:48 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:41973 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726951AbgBGSbr (ORCPT ); Fri, 7 Feb 2020 13:31:47 -0500 Received: by mail-wr1-f65.google.com with SMTP id c9so11504wrw.8 for ; Fri, 07 Feb 2020 10:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0v34gJothHO3j4Q4wlZmrNzO+MkkL5KtAqTgVsXD5t8=; b=c/KE7MDXnr27AuNVH5pVqkgRp1vvz6CmI/2tggk/F4MilQvTzr1FU0WH0WOpDRhYD5 bU7VomlGH5L02fGbPt1PdZygYZWscxoxuOw+yx19ezD5waJBtQs+FIhHVCln4RKo6n48 S0Yc9Vo9/SYWnrlXCxq4ViVRY1xk+5cbc6MaAJTWdQoROaCIUwvasoS5H2MqJ/rLl1J5 5PqiGErFUbIMhdQzKGhkQZyfxn0lHQhyTtNsxRSLLW30pAtk7GKoeMwXg2+y1zH3qXpH kr4esO0v+kS58mRzC28aAmPGjfR9IUIyrWrvibSwlQjw8ElhZkRWu1qQNWT1OedDkMI8 qm5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0v34gJothHO3j4Q4wlZmrNzO+MkkL5KtAqTgVsXD5t8=; b=k/6bnH2CiiAYMCQPQeUxnYn7lJYDxKwXRoz/7zo0VsfFCLO+5IOd2MdeFPR7UMkXWf AvXsOOsRsy0LDrnrfgped8qpDOHahx7Q4FYcdLYM1bYf1TVjTfRQd0Ce9Vf32bb3h/4P fDi5PpwwQo/opEkwjxuU4/QyVbSJef/jBfD5GOBOp1bydrIy4ENyoMTQnDlXB3n1FsJ1 gwuaxM2EICikYHjvWt8SQHTXcPu5OVB6re5mZypYcS08EmZZ8ShBI8nT50M4mRR9Hnfd SmX/dM6itgxWC1wlrANZGWzrJtJfzKjMHRKScCe+XKDiz2L6x1B+X3nectr9VzslrU/1 uPAw== X-Gm-Message-State: APjAAAX1HyTpBh4C6crmLw3NORGLmeAdM7AfCN+0ioPz1mW44ttw1AFz 6CC8ZDG4+8Tw91ZljW3CHITnkJ0/YmOZmtZkCM5k2Q== X-Google-Smtp-Source: APXvYqyVbP4+gSnuDzbO/iK3mOF8OGLPaTetRFZdihOAga1O45m+Zg2UTz4gB3UaPq/25V9fIH2KaNb4aSIPlkv/3Xs= X-Received: by 2002:a5d:42c6:: with SMTP id t6mr313068wrr.151.1581100304442; Fri, 07 Feb 2020 10:31:44 -0800 (PST) MIME-Version: 1.0 References: <20200206140352.6300-1-ardb@kernel.org> <1581092420.7608.15.camel@HansenPartnership.com> In-Reply-To: <1581092420.7608.15.camel@HansenPartnership.com> From: Ard Biesheuvel Date: Fri, 7 Feb 2020 18:31:33 +0000 Message-ID: Subject: Re: [PATCH 0/2] arch-agnostic initrd loading method for EFI systems To: James Bottomley Cc: Laszlo Ersek , Ard Biesheuvel , linux-efi , linux-arm-kernel , Leif Lindholm , Peter Jones , Matthew Garrett , Alexander Graf , Ilias Apalodimas , Heinrich Schuchardt , Daniel Kiper Content-Type: text/plain; charset="UTF-8" Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Fri, 7 Feb 2020 at 16:20, James Bottomley wrote: > > On Fri, 2020-02-07 at 12:23 +0000, Ard Biesheuvel wrote: > > On Fri, 7 Feb 2020 at 09:22, Laszlo Ersek wrote: > > > > > > On 02/07/20 10:09, Laszlo Ersek wrote: > [...] > > > > For example, virt-install's "--location" option "can recognize > > > > certain distribution trees and fetches a bootable kernel/initrd > > > > pair to launch the install". It would be nice to keep that > > > > working for older distros. > > > > > > > > I think LoadFile[2] can co-exist with SimpleFs. > > > > > > > > I also think that the "try SimpleFs first, fall back to > > > > LoadFile[2] second" requirement applies only to the UEFI boot > > > > manager, and not to the kernel's EFI stub. IOW in the new > > > > approach the kernel is free to ignore (abandon) the old approach > > > > for good. > > > > > > ... But that might not be good for compatibility with grub and/or > > > the platform firmware, from the kernel's own perspective, > > > perhaps?... > > > > > > Who is supposed to produce LoadFile2 with the new VenMedia devpath? > > > > > > > What I am ultimately after is a generic GRUB that uses > > LoadImage+Startimage for starting the kernel on all architectures, > > For most boots, we need to pivot to the MoK. A long time ago, I > proposed updating the platform security policy to do an override to > allow MoK to become the security verifier (actually principally so I > could get the gummiboot bootloader to work with the MoK method): > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/lib/security_policy.c > > And I believe all the pivot bootloaders now do this, but the fear was > always this looks a bit like hackery that might not work in some UEFI > implementations. Since we don't really rely on it (shim link loads > after signature verification) we don't know whether the assumption does > break or not. We'll need to get much more comfortable with the > security override before we can let grub do a simple load+start. > I'd like to do something much simpler: let shim override LoadImage and StartImage, and in their implementations, fall back to the firmware ones if necessary. > > and is able to load the initrd from anywhere in an arch agnostic > > manner. > > I think the use case might not really be grub, it's gummiboot, or > systemd-boot as its now called: > No it is definitely GRUB. GRUB today needs to attach to the shim protocol, perform the authentication, measure the payload etc etc, which means it knows far too much about the internals of shim or the fact that it even exists. My ideal bootflow would be where the OS installer looks at the firmware's db/dbx, doesn't bother to install shim if the OS vendor's cert is there, and uses the exact same GRUB regardless of whether shim is part of the bootflow or not. One of the things impeding this is the fact that we cannot load the initrd from anywhere when using loadimage+startimage. > https://wiki.archlinux.org/index.php/systemd-boot > > The standard way of using grub and EFI is to put grub on the EFI > parition but have the kernel and the initrd on the root parition (which > won't be EFI readable). This means we can keep the EFI partition small > and only needing modification when grub is updated, meaning it doesn't > even need mounting at all usually. > > Don't get me wrong, I like the gummiboot way of doing the > LoadImage+StartImage: it's small and clean and doesn't need the shim > protocol, but people like the sophistication grub provides including > its ability to read kernel filesystems, so they're unlikely to change > that. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF780C2BA83 for ; Fri, 7 Feb 2020 18:32:00 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C681821741 for ; Fri, 7 Feb 2020 18:32:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="NGYwNCfo"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="c/KE7MDX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C681821741 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=nX2BWwHRLk1QsgomS49S7l/ego/xk9AvPU4pzV3eHz8=; b=NGYwNCfobMQsJY u8UelAypxymrgidsjEALzp37iHxWRId6x4/hIIfi2au7q+ThwP8QqoaeQGBEz2UBUwlgzfGMgIRVw Pm7MSsmvzI28pQi+SqdMCv+LMti0+PQVry0N1qBJz9i47kpj3GYkaGB/o/hDf2wPXIYdSCXaYVi+b D54DV5aeMuwHZdWyvF/mztu0Vj/gpW613JkgEC3e7yWo24YU45zWjL07MIgmlVJe6yw1evvWhwKxW vSQSACYYiiC4jacFgPZq1kDMqdWDi72ddGy4QAulokAgnnh35vVGMCsOzCl3WRAgTslPE9fqyYth0 RRwFRCGCoBdYXVRfs6LQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j08Px-00079h-M0; Fri, 07 Feb 2020 18:31:53 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j08Pt-00078a-TR for linux-arm-kernel@lists.infradead.org; Fri, 07 Feb 2020 18:31:51 +0000 Received: by mail-wr1-x444.google.com with SMTP id t3so20153wru.7 for ; Fri, 07 Feb 2020 10:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0v34gJothHO3j4Q4wlZmrNzO+MkkL5KtAqTgVsXD5t8=; b=c/KE7MDXnr27AuNVH5pVqkgRp1vvz6CmI/2tggk/F4MilQvTzr1FU0WH0WOpDRhYD5 bU7VomlGH5L02fGbPt1PdZygYZWscxoxuOw+yx19ezD5waJBtQs+FIhHVCln4RKo6n48 S0Yc9Vo9/SYWnrlXCxq4ViVRY1xk+5cbc6MaAJTWdQoROaCIUwvasoS5H2MqJ/rLl1J5 5PqiGErFUbIMhdQzKGhkQZyfxn0lHQhyTtNsxRSLLW30pAtk7GKoeMwXg2+y1zH3qXpH kr4esO0v+kS58mRzC28aAmPGjfR9IUIyrWrvibSwlQjw8ElhZkRWu1qQNWT1OedDkMI8 qm5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0v34gJothHO3j4Q4wlZmrNzO+MkkL5KtAqTgVsXD5t8=; b=ktGTbM3scGg6vipNUohrL4I2QQVUu+GUKNQUQEFl66EGunWb7JAt1dyPTnS6VoZSO2 TCl5mHvKnU7B75CIEvBaTm2DVHY+gAP1Bv8Vpsi5zEVjpyQxu5fE5BPEXviPmAvSC4ad hSVtuJVdYzthABJ8h8BVVsoxFVVEU0eKp1Ntx1n7m3dTJTie4qHKOcH7lbMELd6Y+aYY SUO8SFuvsSqQYOBc04cFfMVTK45CzMTOswd2ghf/5VO8VrjOoYgeIBKMOm+5U9sQHBXq u3XBhOheWb9gWYRTYtJK7rr/6Z+lRUE4SjsqUHtqmSxqFjgsKBcDxivOWqC97y6ho7EN Y2sg== X-Gm-Message-State: APjAAAX43SZWy78vFVZ93u+qcfqQflbDxCJ0B1QgtiohPniMNKUMfbAm ric6282cGrazvEcWz59ZZl2pBNjsmGBWeDXUCSEeRA== X-Google-Smtp-Source: APXvYqyVbP4+gSnuDzbO/iK3mOF8OGLPaTetRFZdihOAga1O45m+Zg2UTz4gB3UaPq/25V9fIH2KaNb4aSIPlkv/3Xs= X-Received: by 2002:a5d:42c6:: with SMTP id t6mr313068wrr.151.1581100304442; Fri, 07 Feb 2020 10:31:44 -0800 (PST) MIME-Version: 1.0 References: <20200206140352.6300-1-ardb@kernel.org> <1581092420.7608.15.camel@HansenPartnership.com> In-Reply-To: <1581092420.7608.15.camel@HansenPartnership.com> From: Ard Biesheuvel Date: Fri, 7 Feb 2020 18:31:33 +0000 Message-ID: Subject: Re: [PATCH 0/2] arch-agnostic initrd loading method for EFI systems To: James Bottomley X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200207_103149_983235_81D472D0 X-CRM114-Status: GOOD ( 26.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-efi , Alexander Graf , Heinrich Schuchardt , Daniel Kiper , Ilias Apalodimas , Matthew Garrett , Peter Jones , Leif Lindholm , Laszlo Ersek , Ard Biesheuvel , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 7 Feb 2020 at 16:20, James Bottomley wrote: > > On Fri, 2020-02-07 at 12:23 +0000, Ard Biesheuvel wrote: > > On Fri, 7 Feb 2020 at 09:22, Laszlo Ersek wrote: > > > > > > On 02/07/20 10:09, Laszlo Ersek wrote: > [...] > > > > For example, virt-install's "--location" option "can recognize > > > > certain distribution trees and fetches a bootable kernel/initrd > > > > pair to launch the install". It would be nice to keep that > > > > working for older distros. > > > > > > > > I think LoadFile[2] can co-exist with SimpleFs. > > > > > > > > I also think that the "try SimpleFs first, fall back to > > > > LoadFile[2] second" requirement applies only to the UEFI boot > > > > manager, and not to the kernel's EFI stub. IOW in the new > > > > approach the kernel is free to ignore (abandon) the old approach > > > > for good. > > > > > > ... But that might not be good for compatibility with grub and/or > > > the platform firmware, from the kernel's own perspective, > > > perhaps?... > > > > > > Who is supposed to produce LoadFile2 with the new VenMedia devpath? > > > > > > > What I am ultimately after is a generic GRUB that uses > > LoadImage+Startimage for starting the kernel on all architectures, > > For most boots, we need to pivot to the MoK. A long time ago, I > proposed updating the platform security policy to do an override to > allow MoK to become the security verifier (actually principally so I > could get the gummiboot bootloader to work with the MoK method): > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/lib/security_policy.c > > And I believe all the pivot bootloaders now do this, but the fear was > always this looks a bit like hackery that might not work in some UEFI > implementations. Since we don't really rely on it (shim link loads > after signature verification) we don't know whether the assumption does > break or not. We'll need to get much more comfortable with the > security override before we can let grub do a simple load+start. > I'd like to do something much simpler: let shim override LoadImage and StartImage, and in their implementations, fall back to the firmware ones if necessary. > > and is able to load the initrd from anywhere in an arch agnostic > > manner. > > I think the use case might not really be grub, it's gummiboot, or > systemd-boot as its now called: > No it is definitely GRUB. GRUB today needs to attach to the shim protocol, perform the authentication, measure the payload etc etc, which means it knows far too much about the internals of shim or the fact that it even exists. My ideal bootflow would be where the OS installer looks at the firmware's db/dbx, doesn't bother to install shim if the OS vendor's cert is there, and uses the exact same GRUB regardless of whether shim is part of the bootflow or not. One of the things impeding this is the fact that we cannot load the initrd from anywhere when using loadimage+startimage. > https://wiki.archlinux.org/index.php/systemd-boot > > The standard way of using grub and EFI is to put grub on the EFI > parition but have the kernel and the initrd on the root parition (which > won't be EFI readable). This means we can keep the EFI partition small > and only needing modification when grub is updated, meaning it doesn't > even need mounting at all usually. > > Don't get me wrong, I like the gummiboot way of doing the > LoadImage+StartImage: it's small and clean and doesn't need the shim > protocol, but people like the sophistication grub provides including > its ability to read kernel filesystems, so they're unlikely to change > that. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel