On Fri, Jun 17, 2022 at 07:58:37AM -0400, Mimi Zohar wrote:
On Fri, 2022-06-17 at 11:57 +0800, Coiby Xu wrote:
>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.
We're saying the same thing, just differently. Your wording describes
secure boot, how it is established, and who/what is responsible for it.
I don't think those details are needed. I originally said,
I think I'm addressing a different concern or case. If kexec_file_load is going
to verify a kernel image signature, what keys is it going to trust and why? I
believe explaining the root trust for different keyrings is to answer this
question. When a bootloader verifies a kernel image signature, the trust is
based on verification of the kernel image signature which we both agree. But
what if a bootloader doesn't do the verification?
.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. On a physical system in
a secure boot environment, this trust is rooted in HW.
The last line should have said, "For example, on a physical system in a
...".
thanks,
Mimi
--
Best regards,
Coiby
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
