linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Coiby Xu <coxu@redhat.com>
To: kexec@lists.infradead.org, linux-integrity@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	linux-arm-kernel@lists.infradead.org,
	Michal Suchanek <msuchanek@suse.de>, Baoquan He <bhe@redhat.com>,
	Dave Young <dyoung@redhat.com>, Will Deacon <will@kernel.org>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Chun-Yi Lee <jlee@suse.com>
Subject: [PATCH v10 0/4] unify the keyrings of arm64 and s390 with x86 to verify kexec'ed kernel signature
Date: Thu, 14 Jul 2022 21:40:23 +0800	[thread overview]
Message-ID: <20220714134027.394370-1-coxu@redhat.com> (raw)

Currently when loading a kernel image via the kexec_file_load() system
call, x86 can make use of three keyrings i.e. the .builtin_trusted_keys,
.secondary_trusted_keys and .platform keyrings to verify a signature.
However, arm64 and s390 can only use the .builtin_trusted_keys and
.platform keyring respectively. For example, one resulting problem is
kexec'ing a kernel image  would be rejected with the error "Lockdown:
kexec: kexec of unsigned images is restricted; see man
kernel_lockdown.7".

This patch set enables arm64 and s390 to make use of the same keyrings
as x86 to verify the signature kexec'ed kernel image.

The recently introduced .machine keyring impacts the roots of trust by
linking the .machine keyring to the .secondary keyring. The roots of
trust for different keyrings are described as follows,

.builtin_trusted_keys:

Keys may be built into the kernel during build or inserted into memory
reserved for keys post build. The root of trust is based on verification
of the kernel image signature. For example, on a physical system in a
secure boot environment, this trust is rooted in hardware.

.machine:

If the end-users choose to trust the keys provided by first-stage UEFI
bootloader shim i.e. Machine Owner Keys (MOK keys), the keys will be
added to this keyring which is linked to the .secondary_trusted_keys
keyring as the same as the .builtin_trusted_keys keyring. Shim has
built-in keys from a Linux distribution or the end-users-enrolled keys.
So the root of trust of this keyring is either a Linux distribution
vendor or the end-users.

.secondary_trusted_keys:

Certificates signed by keys on the .builtin_trusted_keys, .machine, or
existing keys on the .secondary_trusted_keys keryings may be loaded
onto the .secondary_trusted_keys keyring. This establishes a signature
chain of trust based on keys loaded on either the .builtin_trusted_keys
or .machine keyrings, if configured and enabled.

.platform:

The .platform keyring consist of UEFI db and MOK keys which are used by
shim to verify the first boot kernel's image signature. If end-users
choose to trust MOK keys and the kernel has the .machine keyring
enabled, the .platform keyring only consists of UEFI db keys since the
MOK keys are added to the .machine keyring instead. Because the
end-users could also enroll their own MOK keys, the root of trust could
be hardware and the end-users.

The 3rd arm64 patch depends on Naven's patch "[PATCH 1/2] kexec_file:
Drop weak attribute from functions" [2] and the first two patches.
With Naven's patch first applied to the next-integrity branch, I can
confirm these patches are directly appliable to the next-integrity
branch without any conflict. The 4th s390 patch can be applied
independently.

In v9, I've tested the patch set on 5.19.0-rc2 and it works as expected.

For arm64, the tests were done as follows,
  1. build 5.19.0-rc2
  2. generate keys and add them to .secondary_trusted_keys, MOK, UEFI
     db;
  3. sign different kernel images with different keys including keys
     from .builtin_trusted_key, .secondary_trusted_keys keyring, a UEFI db
     key and MOK key
  4. Without lockdown, all kernel images can be kexec'ed; with lockdown
     enabled, only the kernel image signed by the key from the
     .builtin_trusted_key keyring can be kexec'ed

For 390, I commented out the code that skips signature verification when
secure boot is not enabled since the testing machine doesn't supports
secure boot and can confirm before applying the patch, kernel images
signed by keys from .builtin_trusted_key, .secondary_trusted_keys
couldn't be kexec'ed when lockdown is enabled; after applying the patch,
those kernel images could be kexec'ed.

v10:
 - resolve conflict with Naveen's patch which drops weak attribute of
   arch_kexec_kernel_verify_sig

v9:
 - improve cover letter, subject line and commit messages, expecially
   regarding the root of trust of different keyrings and the .machine
   keyring [Mimi]
 - fix two code format issues [Mimi]
 - add test results [Mimi]

v8:
 - drop "Cc: stable@vger.kernel.org" for the first two prerequisite
   patches [Baoquan]

v7:
 - drop the Fixes tag for the 2nd patch and add patch prerequisites
   [Baoquan]
 - improve cover letter

v6:
 - integrate the first three patches of "[PATCH 0/4] Unifrom keyring
   support across architectures and functions" from Michal [1]
 - improve commit message [Baoquan, Michal]
 - directly assign kexec_kernel_verify_pe_sig to
   kexec_file_ops->verify_sig [Michal]

v5:
 - improve commit message [Baoquan]

v4:
 - fix commit reference format issue and other checkpatch.pl warnings [Baoquan]

v3:
 - s/arch_kexec_kernel_verify_pe_sig/kexec_kernel_verify_pe_sig [Eric]
 - clean up arch_kexec_kernel_verify_sig [Eric]

v2:
 - only x86_64 and arm64 need to enable PE file signature check [Dave]

[1] https://lore.kernel.org/lkml/cover.1644953683.git.msuchanek@suse.de/
[2] https://lore.kernel.org/lkml/cover.1656659357.git.naveen.n.rao@linux.vnet.ibm.com/T/#mbd23f46b3714c3c9eecc7484c832a5af49bfa340

Coiby Xu (3):
  kexec: clean up arch_kexec_kernel_verify_sig
  kexec, KEYS: make the code in bzImage64_verify_sig generic
  arm64: kexec_file: use more system keyrings to verify kernel image
    signature

Michal Suchanek (1):
  kexec, KEYS, s390: Make use of built-in and secondary keyring for
    signature verification

 arch/arm64/kernel/kexec_image.c       | 11 +-----
 arch/s390/kernel/machine_kexec_file.c | 18 +++++++---
 arch/x86/kernel/kexec-bzimage64.c     | 20 +----------
 include/linux/kexec.h                 |  6 ++--
 kernel/kexec_file.c                   | 50 ++++++++++++++++-----------
 5 files changed, 49 insertions(+), 56 deletions(-)

-- 
2.35.3


             reply	other threads:[~2022-07-14 13:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-14 13:40 Coiby Xu [this message]
2022-07-14 13:40 ` [PATCH v10 1/4] kexec: clean up arch_kexec_kernel_verify_sig Coiby Xu
2022-07-14 13:40 ` [PATCH v10 2/4] kexec, KEYS: make the code in bzImage64_verify_sig generic Coiby Xu
2022-07-14 13:40 ` [PATCH v10 3/4] arm64: kexec_file: use more system keyrings to verify kernel image signature Coiby Xu
2022-07-14 13:40 ` [PATCH v10 4/4] kexec, KEYS, s390: Make use of built-in and secondary keyring for signature verification Coiby Xu

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=20220714134027.394370-1-coxu@redhat.com \
    --to=coxu@redhat.com \
    --cc=bhe@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=jlee@suse.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=msuchanek@suse.de \
    --cc=will@kernel.org \
    --cc=zohar@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).