From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Ard Biesheuvel <ardb@kernel.org>,
linux-efi <linux-efi@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Laszlo Ersek <lersek@redhat.com>,
Leif Lindholm <leif@nuviainc.com>,
Peter Jones <pjones@redhat.com>,
Matthew Garrett <mjg59@google.com>,
Alexander Graf <agraf@csgraf.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Daniel Kiper <daniel.kiper@oracle.com>
Subject: Re: [PATCH 0/2] arch-agnostic initrd loading method for EFI systems
Date: Fri, 7 Feb 2020 19:47:46 +0000 [thread overview]
Message-ID: <CAKv+Gu8Z3=cqbNxspLXAgM_8wEm+to2TWRjpaaC231MbwL2Ycw@mail.gmail.com> (raw)
In-Reply-To: <20200207184532.GA3276112@rani.riverdale.lan>
On Fri, 7 Feb 2020 at 18:45, Arvind Sankar <nivedita@alum.mit.edu> 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.
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: linux-efi <linux-efi@vger.kernel.org>,
Alexander Graf <agraf@csgraf.de>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Daniel Kiper <daniel.kiper@oracle.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Matthew Garrett <mjg59@google.com>,
Peter Jones <pjones@redhat.com>,
Leif Lindholm <leif@nuviainc.com>,
Laszlo Ersek <lersek@redhat.com>,
Ard Biesheuvel <ardb@kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/2] arch-agnostic initrd loading method for EFI systems
Date: Fri, 7 Feb 2020 19:47:46 +0000 [thread overview]
Message-ID: <CAKv+Gu8Z3=cqbNxspLXAgM_8wEm+to2TWRjpaaC231MbwL2Ycw@mail.gmail.com> (raw)
In-Reply-To: <20200207184532.GA3276112@rani.riverdale.lan>
On Fri, 7 Feb 2020 at 18:45, Arvind Sankar <nivedita@alum.mit.edu> 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
next prev parent reply other threads:[~2020-02-07 19:47 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 14:03 [PATCH 0/2] arch-agnostic initrd loading method for EFI systems Ard Biesheuvel
2020-02-06 14:03 ` Ard Biesheuvel
2020-02-06 14:03 ` [PATCH 1/2] efi/libstub: add support for loading the initrd from a device path Ard Biesheuvel
2020-02-06 14:03 ` Ard Biesheuvel
2020-02-06 18:26 ` Heinrich Schuchardt
2020-02-06 18:26 ` Heinrich Schuchardt
2020-02-06 18:46 ` Ilias Apalodimas
2020-02-06 18:46 ` Ilias Apalodimas
2020-02-06 19:15 ` Heinrich Schuchardt
2020-02-06 19:15 ` Heinrich Schuchardt
2020-02-06 20:09 ` Ilias Apalodimas
2020-02-06 20:09 ` Ilias Apalodimas
2020-02-06 22:49 ` Heinrich Schuchardt
2020-02-06 22:49 ` Heinrich Schuchardt
2020-02-07 7:35 ` Ilias Apalodimas
2020-02-07 7:35 ` Ilias Apalodimas
2020-02-06 22:35 ` Ard Biesheuvel
2020-02-06 22:35 ` Ard Biesheuvel
2020-02-07 0:01 ` Heinrich Schuchardt
2020-02-07 0:01 ` Heinrich Schuchardt
2020-02-07 0:21 ` Ard Biesheuvel
2020-02-07 0:21 ` Ard Biesheuvel
2020-02-07 0:57 ` Heinrich Schuchardt
2020-02-07 0:57 ` Heinrich Schuchardt
2020-02-07 8:12 ` Ard Biesheuvel
2020-02-07 8:12 ` Ard Biesheuvel
2020-02-07 13:30 ` Heinrich Schuchardt
2020-02-07 13:30 ` Heinrich Schuchardt
2020-02-07 13:58 ` Ard Biesheuvel
2020-02-07 13:58 ` Ard Biesheuvel
2020-02-07 14:18 ` Alexander Graf
2020-02-07 14:18 ` Alexander Graf
2020-02-07 15:30 ` Ard Biesheuvel
2020-02-07 15:30 ` Ard Biesheuvel
2020-02-07 15:35 ` Heinrich Schuchardt
2020-02-07 15:35 ` Heinrich Schuchardt
2020-02-07 11:09 ` Laszlo Ersek
2020-02-07 11:09 ` Laszlo Ersek
2020-02-07 11:03 ` Laszlo Ersek
2020-02-07 11:03 ` Laszlo Ersek
2020-02-07 9:48 ` Laszlo Ersek
2020-02-07 9:48 ` Laszlo Ersek
2020-02-07 12:36 ` Ard Biesheuvel
2020-02-07 12:36 ` Ard Biesheuvel
2020-02-10 14:26 ` Laszlo Ersek
2020-02-10 14:26 ` Laszlo Ersek
2020-02-09 6:39 ` Lukas Wunner
2020-02-09 11:35 ` Ard Biesheuvel
2020-02-09 11:35 ` Ard Biesheuvel
2020-02-06 14:03 ` [PATCH 2/2] efi/libstub: take noinitrd cmdline argument into account for devpath initrd Ard Biesheuvel
2020-02-06 14:03 ` Ard Biesheuvel
2020-02-06 18:33 ` Heinrich Schuchardt
2020-02-06 18:33 ` Heinrich Schuchardt
2020-02-06 23:44 ` Ard Biesheuvel
2020-02-06 23:44 ` Ard Biesheuvel
2020-02-12 16:01 ` Peter Jones
2020-02-12 16:01 ` Peter Jones
2020-02-07 9:09 ` [PATCH 0/2] arch-agnostic initrd loading method for EFI systems Laszlo Ersek
2020-02-07 9:09 ` Laszlo Ersek
2020-02-07 9:22 ` Laszlo Ersek
2020-02-07 9:22 ` Laszlo Ersek
2020-02-07 12:23 ` Ard Biesheuvel
2020-02-07 12:23 ` Ard Biesheuvel
2020-02-07 16:20 ` James Bottomley
2020-02-07 16:20 ` James Bottomley
2020-02-07 18:31 ` Ard Biesheuvel
2020-02-07 18:31 ` Ard Biesheuvel
2020-02-07 19:54 ` James Bottomley
2020-02-07 19:54 ` James Bottomley
2020-02-07 20:03 ` Ard Biesheuvel
2020-02-07 20:03 ` Ard Biesheuvel
2020-02-07 18:45 ` Arvind Sankar
2020-02-07 18:45 ` Arvind Sankar
2020-02-07 19:47 ` Ard Biesheuvel [this message]
2020-02-07 19:47 ` Ard Biesheuvel
2020-02-07 20:26 ` Arvind Sankar
2020-02-07 20:26 ` Arvind Sankar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKv+Gu8Z3=cqbNxspLXAgM_8wEm+to2TWRjpaaC231MbwL2Ycw@mail.gmail.com' \
--to=ard.biesheuvel@linaro.org \
--cc=agraf@csgraf.de \
--cc=ardb@kernel.org \
--cc=daniel.kiper@oracle.com \
--cc=ilias.apalodimas@linaro.org \
--cc=leif@nuviainc.com \
--cc=lersek@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=mjg59@google.com \
--cc=nivedita@alum.mit.edu \
--cc=pjones@redhat.com \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.