Linux kbuild/kconfig development
 help / color / mirror / Atom feed
From: Jeremy Linton <jeremy.linton@arm.com>
To: linux-kernel@vger.kernel.org
Cc: akpm@linux-foundation.org, hch@lst.de,
	gregkh@linuxfoundation.org, graf@amazon.com, lukas@wunner.de,
	wufan@linux.microsoft.com, brauner@kernel.org,
	jsperbeck@google.com, ardb@kernel.org,
	linux-crypto@vger.kernel.org, linux-kbuild@vger.kernel.org,
	keyrings@vger.kernel.org, Jeremy Linton <jeremy.linton@arm.com>
Subject: [RFC 0/5] Another initramfs signature checking set
Date: Tue, 15 Oct 2024 17:22:30 -0500	[thread overview]
Message-ID: <20241015222235.71040-1-jeremy.linton@arm.com> (raw)

With the advent of UKI's wrapping kernel and cpio archives up into
single UEFI PE executables it seems like its probably time to
reconsider whether the core idea of signing the initrd and verifying
it in its entirely is a useful function of the core kernel.

Moving this functionality in the kernel should provide a similar
security statement to the UKIs with a more traditional kernel + initrd
boot flow and the ability to have a single kernel image that
selects between multiple signed initrd images. Say a normal boot
image, and a recovery image.

This set is a very basic implementation of that concept using the kernel
built in trusted keyring, and a signature format that is similar to the
existing module signature. The core change is quite trivial with the larger
questions around the policy for enforcing or simply checking
for a valid signature. I've considered various policies, tying it to
lockdown/etc but this set simply enforces it by default with an kernel
parameter to override the behavior.

Outside of the core patch the largest change revolves around making
sure that the asymmetric key and built in cert/keyring/blacklist logic
is started much earlier in the boot process than normal. This means
that beyond the hacky _initcall changes in patch 2 there are a bit of
additional Kconfig changes necessary.

Finally, before the RFC is dropped there are a number of
/Documentation changes that will be completed as needed.

Jeremy Linton (5):
  initramfs: Add initramfs signature checking
  KEYS/certs: Start the builtin key and cert system earlier
  initramfs: Use existing module signing infrastructure
  sign-file: Add -i option to sign initramfs images
  initramfs: Enforce initramfs signature

 certs/blacklist.c                        |  2 +-
 certs/system_keyring.c                   |  4 +-
 crypto/asymmetric_keys/asymmetric_type.c |  2 +-
 crypto/asymmetric_keys/x509_public_key.c |  2 +-
 include/linux/initrd.h                   |  3 +
 init/initramfs.c                         | 84 +++++++++++++++++++++++-
 scripts/sign-file.c                      | 11 +++-
 usr/Kconfig                              |  9 +++
 8 files changed, 109 insertions(+), 8 deletions(-)

-- 
2.46.0


             reply	other threads:[~2024-10-15 22:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-15 22:22 Jeremy Linton [this message]
2024-10-15 22:22 ` [RFC 1/5] initramfs: Add initramfs signature checking Jeremy Linton
2024-10-15 22:22 ` [RFC 2/5] KEYS/certs: Start the builtin key and cert system earlier Jeremy Linton
2024-10-15 22:22 ` [RFC 3/5] initramfs: Use existing module signing infrastructure Jeremy Linton
2024-10-15 22:22 ` [RFC 4/5] sign-file: Add -i option to sign initramfs images Jeremy Linton
2024-10-15 22:22 ` [RFC 5/5] initramfs: Enforce initramfs signature Jeremy Linton

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=20241015222235.71040-1-jeremy.linton@arm.com \
    --to=jeremy.linton@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=brauner@kernel.org \
    --cc=graf@amazon.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=jsperbeck@google.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=wufan@linux.microsoft.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox