kexec.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Coiby Xu <coxu@redhat.com>
Cc: kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
	Michal Suchanek <msuchanek@suse.de>, Baoquan He <bhe@redhat.com>,
	Dave Young <dyoung@redhat.com>, Will Deacon <will@kernel.org>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Chun-Yi Lee <jlee@suse.com>
Subject: Re: [PATCH v8 0/4] use more system keyrings to verify arm64 and s390 kexec kernel image signature
Date: Fri, 17 Jun 2022 07:58:37 -0400	[thread overview]
Message-ID: <dc23f46380e6fb218181e685ad2f0a1db34500fe.camel@linux.ibm.com> (raw)
In-Reply-To: <20220617035724.uyc7mp4n5gdlzta5@Rk>

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2022-06-17 12:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12  7:01 [PATCH v8 0/4] use more system keyrings to verify arm64 and s390 kexec kernel image signature Coiby Xu
2022-05-12  7:01 ` [PATCH v8 1/4] kexec: clean up arch_kexec_kernel_verify_sig Coiby Xu
2022-06-09 21:57   ` Mimi Zohar
2022-05-12  7:01 ` [PATCH v8 2/4] kexec, KEYS: make the code in bzImage64_verify_sig generic Coiby Xu
2022-05-12  7:21   ` Baoquan He
2022-06-09 22:18   ` Mimi Zohar
2022-06-16  1:47     ` Coiby Xu
2022-05-12  7:01 ` [PATCH v8 3/4] arm64: kexec_file: use more system keyrings to verify kernel image signature Coiby Xu
2022-06-09 23:15   ` Mimi Zohar
2022-06-16  1:22     ` Coiby Xu
2022-06-17  9:34     ` Michal Suchánek
2022-05-12  7:01 ` [PATCH v8 4/4] kexec, KEYS, s390: Make use of built-in and secondary keyring for signature verification Coiby Xu
2022-05-18 11:29   ` Heiko Carstens
2022-05-19  0:39     ` Baoquan He
2022-05-19 11:56       ` Mimi Zohar
2022-05-19 14:22         ` Baoquan He
2022-05-19 17:11           ` Michal =?unknown-8bit?q?Such=C3=A1nek?=
2022-06-16  1:46             ` Coiby Xu
2022-05-20 17:04 ` [PATCH v8 0/4] use more system keyrings to verify arm64 and s390 kexec kernel image signature Mimi Zohar
2022-05-25  9:59   ` Coiby Xu
2022-05-25 13:30     ` Mimi Zohar
2022-05-27 13:43       ` Coiby Xu
2022-05-27 16:45         ` Mimi Zohar
2022-06-16  1:15           ` Coiby Xu
2022-06-17  3:57             ` Coiby Xu
2022-06-17 11:58               ` Mimi Zohar [this message]
2022-06-20 13:14                 ` Coiby Xu
2022-06-09 15:35         ` Mimi Zohar
2022-06-16  1:21           ` Coiby Xu
2022-06-17 12:06             ` Mimi Zohar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dc23f46380e6fb218181e685ad2f0a1db34500fe.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=bhe@redhat.com \
    --cc=coxu@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=jlee@suse.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=msuchanek@suse.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).