From: Peter Jones <pjones@redhat.com> To: Ard Biesheuvel <ardb@kernel.org> Cc: linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, lersek@redhat.com, leif@nuviainc.com, mjg59@google.com, agraf@csgraf.de, ilias.apalodimas@linaro.org, xypron.glpk@gmx.de, daniel.kiper@oracle.com Subject: Re: [PATCH 2/2] efi/libstub: take noinitrd cmdline argument into account for devpath initrd Date: Wed, 12 Feb 2020 11:01:16 -0500 [thread overview] Message-ID: <20200212160116.3xypcgmtafj7fm47@redhat.com> (raw) In-Reply-To: <20200206140352.6300-3-ardb@kernel.org> On Thu, Feb 06, 2020 at 02:03:52PM +0000, Ard Biesheuvel wrote: > One of the advantages of using what basically amounts to a callback > interface into the bootloader for loading the initrd is that it provides > a natural place for the bootloader or firmware to measure the initrd > contents while they are being passed to the kernel. > > Unfortunately, this is not a guarantee that the initrd will in fact be > loaded and its /init invoked by the kernel, since the command line may > contain the 'noinitrd' option, in which case the initrd is ignored, but > this will not be reflected in the PCR that covers the initrd measurement. > > This could be addressed by measuring the command line as well, and > including that PCR in the attestation policy, but this locks down the > command line completely, which may be too restrictive. In practice I think we need to be measuring the command line anyway. In current existing deployments, we measure kernel and initramfs into PCR9, and measure the kernel command line into PCR8 (both are reserved in the TIS for OS use). This allows users farther down the stack to choose whether which things they seal against, based on their requirements. > So let's take the noinitrd argument into account in the stub, too. This > forces the PCR that covers the initrd to assume a different value when > noinitrd is passed, allowing an attestation policy to disregard the > command line if there is no need to take its measurement into account > for other reasons. I think we also need to log a capping EV_SEPARATOR event with an log entry that says it's for noinitrd into PCR9, in order to prevent any scenarios where an attacker prevents the normal initramfs from loading, and then replays the events from a prior log in order to unseal secrets. -- Peter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Jones <pjones@redhat.com> To: Ard Biesheuvel <ardb@kernel.org> Cc: linux-efi@vger.kernel.org, xypron.glpk@gmx.de, daniel.kiper@oracle.com, ilias.apalodimas@linaro.org, mjg59@google.com, agraf@csgraf.de, leif@nuviainc.com, lersek@redhat.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/2] efi/libstub: take noinitrd cmdline argument into account for devpath initrd Date: Wed, 12 Feb 2020 11:01:16 -0500 [thread overview] Message-ID: <20200212160116.3xypcgmtafj7fm47@redhat.com> (raw) In-Reply-To: <20200206140352.6300-3-ardb@kernel.org> On Thu, Feb 06, 2020 at 02:03:52PM +0000, Ard Biesheuvel wrote: > One of the advantages of using what basically amounts to a callback > interface into the bootloader for loading the initrd is that it provides > a natural place for the bootloader or firmware to measure the initrd > contents while they are being passed to the kernel. > > Unfortunately, this is not a guarantee that the initrd will in fact be > loaded and its /init invoked by the kernel, since the command line may > contain the 'noinitrd' option, in which case the initrd is ignored, but > this will not be reflected in the PCR that covers the initrd measurement. > > This could be addressed by measuring the command line as well, and > including that PCR in the attestation policy, but this locks down the > command line completely, which may be too restrictive. In practice I think we need to be measuring the command line anyway. In current existing deployments, we measure kernel and initramfs into PCR9, and measure the kernel command line into PCR8 (both are reserved in the TIS for OS use). This allows users farther down the stack to choose whether which things they seal against, based on their requirements. > So let's take the noinitrd argument into account in the stub, too. This > forces the PCR that covers the initrd to assume a different value when > noinitrd is passed, allowing an attestation policy to disregard the > command line if there is no need to take its measurement into account > for other reasons. I think we also need to log a capping EV_SEPARATOR event with an log entry that says it's for noinitrd into PCR9, in order to prevent any scenarios where an attacker prevents the normal initramfs from loading, and then replays the events from a prior log in order to unseal secrets. -- Peter _______________________________________________ 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-12 16:01 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 [this message] 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 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=20200212160116.3xypcgmtafj7fm47@redhat.com \ --to=pjones@redhat.com \ --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=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: linkBe 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.