On Thu, Jun 16, 2022 at 09:15:06AM +0800, Coiby Xu wrote:
Hi Mimi,
Thanks for carefully reviewing the covert letter and patches and
suggesting various improvements! And sorry for the late reply as I need
some time to learn more about secure boot, lockdown and IMA to better
make sense of what you mean.
On Fri, May 27, 2022 at 12:45:54PM -0400, Mimi Zohar wrote:
new cover letter here to collect new feedback from you thus we
can avoid unnecessary rounds of patch set.
Agreed. Much better. Just a couple of nits.
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 signature.
Either "a signature" or "signatures".
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 very the signature kexec'ed kernel image.
Fix "very". Perhaps "verify the kexec'ed kernel image signature".
The recently introduced .machine keyring impacts the roots of trust by
linking the .machine keyring to the .secondary keyring. The roots of
trust of different keyring are described as follows,
"of ... keyring" -> "for the ... keyrings"
Thanks for catching those typos and improving the wording!
.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 the kernel build i.e.
a Linux distribution vendor. On a physical system in a secure boot
environment, this trust is rooted in hardware.
Please look at my response to your question below.
.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 and this keyring is linked to the
Grammatically "and this" needs to be fixed.
How about "the keys will be added to this keyring which is linked to
the..."?
.secondary_trusted_keys keyring as 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 there own MOK keys, the root of trust could
"there" -> "their"
be hardware or the end-users.
It's always "hardware". "or" -> "and"?
Thanks for catching these issues as well!
<snip>
The root of trusts of the keys in the %.builtin_trusted_keys and
secondary_trusted_keys keyring is a Linux distribution vendor.
The root of trust for each keyring should be described separately.
.builtin_trusted_keys:
For example,
Keys may be built into the kernel during build or inserted into memory
reserved for keys post build. In both of these cases, trust is based
on verification of the kernel image signature.
Correct me if I'm wrong, without secure boot, there is no verification
of the kernel image signature so the root of trust should be trust on
the kernel builder.
No, basing the signature verification on secure boot could not have
been upstreamed.
Thanks for correcting me! I was a bit confused by secure boot and
lockdown and also forgot enabling lockdown automatically when secure
boot is enabled is a downstream feature. Btw, when testing the 4th s390
patch, I found s390 skip signature validation when secure boot is not
enabled, is this a mistake?
// arch/s390/kernel/machine_kexec_file.c
#ifdef CONFIG_KEXEC_SIG
int s390_verify_sig(const char *kernel, unsigned long kernel_len)
{
/* Skip signature verification when not secure IPLed. */
if (!ipl_secure_flag)
return 0;
IMA is based on policy, regardeless of the secure
boot mode. A builtin policy may be specified on the boot command line,
but should be replaced with a more constrained custom policy [1].
Unlike the builtin policy rules, the architecture specific rules are
persistent[2]. The architecture specific rules are normally tied to
the secure boot modes. On OpenPOWER, the architecture specific
"measure" rules are dependent on the trusted boot mode.
The current IMA policy rules can be viewed by cat'ing
<securityfs>/ima/policy.
Thanks for explaining IMA to me! There is still the question of what's
the root of trust for .builtin_trusted_keys when there is no real
signature verification. For example, when CONFIG_KEXEC_SIG is enabled,
the default IMA policy is to not appraise kexec image. Since lockdown is
not enabled by default, there is no real verification as
kimage_validate_signature succeeds even when kexec_image_verify_sig
fails.
I realize my reasoning is incorrect. Actually the signature
verification which establishes the trust on the keys happens in the
bootloader. So IMA appraisal or kimage_validate_signature is irrelevant
to the question of the root of trust of .builtin_trusted_key. For GRUB,
it won't verify the signature by default when secure boot is not enabled.
Thus the question of what's root of trust when there is no signature
verification is still valid.
[1] The builtin policies are not LSM aware. The policy rules need to
be constrained to avoid integrity violations.
[2] arch specific policy rules:
security/integrity/ima/ima_efi.c, arch/powerpc/kernel/ima_arch.c
thanks,
Mimi
--
Best regards,
Coiby
--
Best regards,
Coiby
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
