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, .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 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
