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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 C08F6C2BA83 for ; Fri, 7 Feb 2020 19:47:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 980FB217BA for ; Fri, 7 Feb 2020 19:47:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="ZtenNvpg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727012AbgBGTr7 (ORCPT ); Fri, 7 Feb 2020 14:47:59 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:40608 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726988AbgBGTr7 (ORCPT ); Fri, 7 Feb 2020 14:47:59 -0500 Received: by mail-wr1-f67.google.com with SMTP id t3so299296wru.7 for ; Fri, 07 Feb 2020 11:47:57 -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=ADmEob5aCHIMZYdk17bc2JtUL+648UgN60jHGzFUmnQ=; b=ZtenNvpggSNUBFW84py2rlNqNs1p27CT9g4Y0dQKsE0VKS/mqmxCYdKR44F4KrFJmH ccgRRcEazb4hunqtwY7yIYDj1VI46LGOzVIA1W3gOalQEHUL4XoeKvTAwL4LuWC7wEfW ku9j4hCIBFMt2Y6ZbkfWtXyv887LDZ2Ka8QncGwcHx4pHRG7UqtVJrnYarZuytQouWff 1IqZL2Qa70K/tU+n6B2Df3bQS2a2DKxwqYeKbg3UmzWAjmj1ybwWKOvJzy1IArws51Q6 VR7tmPpl6QbokDZMdKvp8ApdMtLCzEn/oW7hOcCEXhWH1uHKy5lV+e4K7EWISk+C3Igu axRA== 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=ADmEob5aCHIMZYdk17bc2JtUL+648UgN60jHGzFUmnQ=; b=ifZvKw6S7Kb2ZHfmnV3dbFIe1Z74IIuXk/7359juWsQcQt2cmS12rv6Bo2wQAJyIS7 3glJhgmnvf1cJtg4rs2aY5n3FUjI5/N0uKRn7v/ttPfWh+/jgi2YDy1SwbhI0MVOImRN EaRr35VzXYL9kgB5MD1nMbeBraoskCs+GwnXvPFrhtwXiEpFohq+pIqHmCyFN8+3yzQ0 Mp0FbzrMz6YTxvCwg4G8BOInITWpj2yjDN3eN/7eyRnHqkItWRbanaPGAvl90qKewflm zZWEvufNHnhNrfEYhc5sDWaNT8a3rIHH02Nyt5tAQsCbAtzqVHYGUyMXtWqo/7tvcH0x 6PbQ== X-Gm-Message-State: APjAAAU8F5+ErVeeDVn3Rms8zXW3Ofob3ER3tGH/qVPJcSEvqJqA/GLr hFVLvjhMyLneCOHjv4tT3E2CTapaaup8ty2BmMOwOfnR2AIZgA== X-Google-Smtp-Source: APXvYqy8ulALAFMRrpiERJSH7DxxaKYXZW/FVT6fUplf6OymnaPN0l0tMb7TfG90cZJkFEOJdBoIgpGS95aYvd5xNtc= X-Received: by 2002:adf:fd8d:: with SMTP id d13mr643736wrr.208.1581104877140; Fri, 07 Feb 2020 11:47:57 -0800 (PST) MIME-Version: 1.0 References: <20200206140352.6300-1-ardb@kernel.org> <20200207184532.GA3276112@rani.riverdale.lan> In-Reply-To: <20200207184532.GA3276112@rani.riverdale.lan> From: Ard Biesheuvel Date: Fri, 7 Feb 2020 19:47:46 +0000 Message-ID: Subject: Re: [PATCH 0/2] arch-agnostic initrd loading method for EFI systems To: Arvind Sankar Cc: Ard Biesheuvel , linux-efi , linux-arm-kernel , Laszlo Ersek , 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 18:45, Arvind Sankar wrote: > > On Thu, Feb 06, 2020 at 02:03:50PM +0000, Ard Biesheuvel wrote: > > data structure. It also creates a time window where the initrd data sits > > in memory, and can potentially be corrupted before the kernel is booted. > > > > I don't quite understand the time window aspect -- can you expand on > that? It seems like the same time window exists between when the kernel > is loaded and when it actually runs, no? Why is this more important for > initrd? When using loadimage+startimage, the authentication and measurement of the kernel image occur during the call to loadimage(), even if the source of the load is memory itself, and startimage() is typically called right after. The assumption is that it may help to make this time as short as possible for the initrd as well. 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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 EB304C2BA83 for ; Fri, 7 Feb 2020 19:48:08 +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 BEC7C217BA for ; Fri, 7 Feb 2020 19:48:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="iOSqTPws"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="ZtenNvpg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BEC7C217BA 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=0gQuEofZtB3dquSMiNeesE296XVvUgU+cpW6BasYJUE=; b=iOSqTPwsh7G3DT 37sTUWdAg5EitJGSsMYiiS9vvPeY4ujHul9cTv9x7iaAovQEiFJuxcIaseCOiU75DwhYgJUBmDivp xjdYBBHy9gxwx5nlhTfcYvpMNlLje28W3zvQN4CZa+3o4KYQ/jVRZxNa4HJkDz8nPYmH7hOrvczdT UBRkjqqQMwq2+ds1DGjQjV0hq5/G5JKFo218BrhN/rMjTFKGnAh18rnR7uBEMM/YVuhWPNFFiOTV/ 0FCsfYTZ0JNhbUGgrLk+OyWrGRSdXy1DQIkx0O8SQVXYkuKSos8v79TgEjNu7KNE5pF8HsL9cqKYE U6OWNokChVbfEbSVOCAg==; 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 1j09bd-0006k2-Hk; Fri, 07 Feb 2020 19:48:01 +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 1j09ba-0006jc-H1 for linux-arm-kernel@lists.infradead.org; Fri, 07 Feb 2020 19:47:59 +0000 Received: by mail-wr1-x444.google.com with SMTP id a6so255079wrx.12 for ; Fri, 07 Feb 2020 11:47:58 -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=ADmEob5aCHIMZYdk17bc2JtUL+648UgN60jHGzFUmnQ=; b=ZtenNvpggSNUBFW84py2rlNqNs1p27CT9g4Y0dQKsE0VKS/mqmxCYdKR44F4KrFJmH ccgRRcEazb4hunqtwY7yIYDj1VI46LGOzVIA1W3gOalQEHUL4XoeKvTAwL4LuWC7wEfW ku9j4hCIBFMt2Y6ZbkfWtXyv887LDZ2Ka8QncGwcHx4pHRG7UqtVJrnYarZuytQouWff 1IqZL2Qa70K/tU+n6B2Df3bQS2a2DKxwqYeKbg3UmzWAjmj1ybwWKOvJzy1IArws51Q6 VR7tmPpl6QbokDZMdKvp8ApdMtLCzEn/oW7hOcCEXhWH1uHKy5lV+e4K7EWISk+C3Igu axRA== 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=ADmEob5aCHIMZYdk17bc2JtUL+648UgN60jHGzFUmnQ=; b=WD1resnUTkAIJWslpCoysSHNqfTHiIpRRS1p6YvbFjGJ6ek6bxFsnZ3isatpxepM/n SqUirOaNnicgvFvuBCbVLyX56ZRjFCmYfIJbOY4tISIQ1ymf76LXSe12KRbpZ/r1HqIw CipVdZLiKLeAMOVBTa7qhBWw2LebQ3tqfSPSOzaezaa9vaI+Q+sRIfKqCdjr1nVK+iTH NE0X6Nv9poOawqSfv6xv3npBw4EF7NC16zgffqABNZICPAsUd7f/L1O/ZEjOzKRmaCy9 6kk4XjphGNBemjYDmRF9mRbrckTgsJlFQ385OyXgXsxKpVKfV3Bpr22BeTD8q37PQ2bl xkUQ== X-Gm-Message-State: APjAAAUffhxcU1/T76GseJMX8UpKMzAy/CUFibk1E13v/r9EiooxB0w+ zZMb2F1Xv8myR13sIv56B/iqqgJD/4P2etCmbMARiw== X-Google-Smtp-Source: APXvYqy8ulALAFMRrpiERJSH7DxxaKYXZW/FVT6fUplf6OymnaPN0l0tMb7TfG90cZJkFEOJdBoIgpGS95aYvd5xNtc= X-Received: by 2002:adf:fd8d:: with SMTP id d13mr643736wrr.208.1581104877140; Fri, 07 Feb 2020 11:47:57 -0800 (PST) MIME-Version: 1.0 References: <20200206140352.6300-1-ardb@kernel.org> <20200207184532.GA3276112@rani.riverdale.lan> In-Reply-To: <20200207184532.GA3276112@rani.riverdale.lan> From: Ard Biesheuvel Date: Fri, 7 Feb 2020 19:47:46 +0000 Message-ID: Subject: Re: [PATCH 0/2] arch-agnostic initrd loading method for EFI systems To: Arvind Sankar X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200207_114758_595749_979880BC X-CRM114-Status: GOOD ( 12.88 ) 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 18:45, Arvind Sankar wrote: > > On Thu, Feb 06, 2020 at 02:03:50PM +0000, Ard Biesheuvel wrote: > > data structure. It also creates a time window where the initrd data sits > > in memory, and can potentially be corrupted before the kernel is booted. > > > > I don't quite understand the time window aspect -- can you expand on > that? It seems like the same time window exists between when the kernel > is loaded and when it actually runs, no? Why is this more important for > initrd? When using loadimage+startimage, the authentication and measurement of the kernel image occur during the call to loadimage(), even if the source of the load is memory itself, and startimage() is typically called right after. The assumption is that it may help to make this time as short as possible for the initrd as well. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel