[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190109164824.19708-1-kasong@redhat.com>
Date: Thu, 10 Jan 2019 00:48:22 +0800
From: Kairui Song <kasong@...hat.com>
To: linux-kernel@...r.kernel.org
Cc: dhowells@...hat.com, dwmw2@...radead.org,
jwboyer@...oraproject.org, keyrings@...r.kernel.org,
jmorris@...ei.org, serge@...lyn.com, zohar@...ux.ibm.com,
bauerman@...ux.ibm.com, ebiggers@...gle.com, nayna@...ux.ibm.com,
dyoung@...hat.com, linux-integrity@...r.kernel.org,
kexec@...ts.infradead.org, Kairui Song <kasong@...hat.com>
Subject: [RFC PATCH 0/2] let kexec_file_load use platform keyring to verify the kernel image
Hi,
This is a different approach for the previous patch:
[RFC PATCH 0/1] KEYS, integrity: Link .platform keyring to .secondary_trusted_keys
make kexec_file_load be able to verify the kernel image against keys
provided by platform or firmware.
This patch adds a .platform_trusted_keys in system_keyring as the reference
to .platform keyring in integrity subsystem, when platform keyring is
being initialized it will be updated.
Another thing on my mind is that now kexec_file_load will still relay on
CONFIG_INTEGRITY_PLATFORM_KEYRING and all its dependencies to be enabled
to be able to verify the image against firmware keys. I'm thinking about
to have something like CONFIG_PLATFORM_KEYRING and make the .platform
keyring could be enabled for a more wider usage. Not sure if it's a good
idea though.
Tested in a VM with locally signed kernel with pesign and imported the
cert to EFI's MokList variable.
Kairui Song (2):
integrity, KEYS: add a reference to platform keyring
kexec, KEYS: Make use of platform keyring for signature verify
arch/x86/kernel/kexec-bzimage64.c | 13 ++++++++++---
certs/system_keyring.c | 10 +++++++++-
include/keys/system_keyring.h | 5 +++++
include/linux/verification.h | 1 +
security/integrity/digsig.c | 4 ++++
5 files changed, 29 insertions(+), 4 deletions(-)
--
2.20.1
Powered by blists - more mailing lists