summaryrefslogtreecommitdiff
path: root/arch/arm64/kernel/irq.c
diff options
context:
space:
mode:
authorMimi Zohar <zohar@linux.ibm.com>2022-07-15 12:54:01 -0400
committerMimi Zohar <zohar@linux.ibm.com>2022-07-26 15:58:49 -0400
commit88b61b130334212f8f05175e291c04adeb2bf30b (patch)
tree4df1671788f5ace5cffe50430d5d482acca90cc0 /arch/arm64/kernel/irq.c
parentc808a6ec7166105818e698be9ead396233eb91b8 (diff)
parent0828c4a39be57768b8788e8cbd0d84683ea757e5 (diff)
Merge remote-tracking branch 'linux-integrity/kexec-keyrings' into next-integrity
From the cover letter: 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.
Diffstat (limited to 'arch/arm64/kernel/irq.c')
0 files changed, 0 insertions, 0 deletions