On Fri, 2022-06-17 at 11:57 +0800, Coiby Xu wrote:

quoted

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,

.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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel