kexec.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Coiby Xu <coxu@redhat.com>
To: Mimi Zohar <zohar@linux.ibm.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>,
	stable@vger.kernel.org, keyrings@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	James Morse <james.morse@arm.com>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 3/4] arm64: kexec_file: use more system keyrings to verify kernel image signature
Date: Thu, 16 Jun 2022 09:22:32 +0800	[thread overview]
Message-ID: <20220616012232.5rjmukabncqnus5s@Rk> (raw)
In-Reply-To: <e44bb6b11573838417b5d561173c27a1571c94b6.camel@linux.ibm.com>

On Thu, Jun 09, 2022 at 07:15:27PM -0400, Mimi Zohar wrote:
>On Thu, 2022-05-12 at 15:01 +0800, Coiby Xu wrote:
>> Currently, a problem faced by arm64 is if a kernel image is signed by a
>> MOK key, loading it via the kexec_file_load() system call would be
>> rejected with the error "Lockdown: kexec: kexec of unsigned images is
>> restricted; see man kernel_lockdown.7".
>>
>> This happens because image_verify_sig uses only the primary keyring that
>> contains only kernel built-in keys to verify the kexec image.
>
>From the git history it's clear that .platform keyring was upstreamed
>during the same open window as commit 732b7b93d849 ("arm64: kexec_file:
>add kernel signature verification support").   Loading the MOK keys
>onto the .platform keyring was upstreamed much later.  For this reason,
>commit 732b7b93d849 only used keys on the  .builtin_trusted_keys
>keyring.   This patch is now addressing it and the newly upstreamed
>.machine keyring.

Thanks for explaining the history to me!

>
>Only using the .builtin_trusted_keys is the problem statement, which
>should be one of the first lines of the patch description, if not the
>first line.

Thanks for the suggestion! I've provided a new version of commit message
in the end.

>
>>
>> This patch allows to verify arm64 kernel image signature using not only
>> .builtin_trusted_keys but also .platform and .secondary_trusted_keys
>> keyring.
>
>Please remember to update this to include the .machine keyring.

Sure, thanks for the reminder!

>
>>
>> Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification support")
>
>Since the MOK keys weren't loaded onto the .platform keyring until much
>later, I would not classify this as a fix.

For this Fixes tag, I mean arm64 couldn't make use of the secondary
keyring because a secondary system keyring was introduced long before
commit 732b7b93d849 ("arm64: kexec_file: add kernel signature
verification support"),

	commit d3bfe84129f65e0af2450743ebdab33d161d01c9
	Author: David Howells <dhowells@redhat.com>
	Date:   Wed Apr 6 16:14:27 2016 +0100
	
	    certs: Add a secondary system keyring that can be added to dynamically
	
	
	commit 732b7b93d849f8a44886ead563dfb6adec7f4419
	Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
	Date:   Thu Nov 15 14:52:54 2018 +0900
	
	    arm64: kexec_file: add kernel signature verification support

Of course, my commit message is misleading since it talks about MOK key
in the first line. If stating the problem as arm64 only using the
.builtin_trusted_keys as suggested by you, I think this Fixes tag would
make sense. How about the following one?

Currently, when loading a kernel image via the kexec_file_load() system
call, arm64 can only use the .builtin_trusted_keys keyring to verify
a signature whereas x86 can use three more keyrings i.e.
.secondary_trusted_keys, .machine and .platform keyrings. 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 to make use of the same keyrings as x86 to
verify the signature kexec'ed kernel image. 

Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification support")


>
>thanks,
>
>Mimi
>

-- 
Best regards,
Coiby


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2022-06-16  1:25 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 [this message]
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
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=20220616012232.5rjmukabncqnus5s@Rk \
    --to=coxu@redhat.com \
    --cc=bhe@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=james.morse@arm.com \
    --cc=jlee@suse.com \
    --cc=kexec@lists.infradead.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=msuchanek@suse.de \
    --cc=stable@vger.kernel.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=will@kernel.org \
    --cc=zohar@linux.ibm.com \
    /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).