[PATCH v8 0/4] use more system keyrings to verify arm64 and s390 kexec kernel image signature

[Coiby Xu]

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