From: Andrew Morton <akpm@linux-foundation.org> To: Lianbo Jiang <lijiang@redhat.com> Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org, ebiederm@xmission.com, jbohac@suse.cz, jmorris@namei.org, mjg59@google.com, dyoung@redhat.com, bhe@redhat.com Subject: Re: [PATCH v2] kexec: Do not verify the signature without the lockdown or mandatory signature Date: Wed, 17 Jun 2020 12:37:31 -0700 [thread overview] Message-ID: <20200617123731.0dbb039a053a2ef610af59fb@linux-foundation.org> (raw) In-Reply-To: <20200602045952.27487-1-lijiang@redhat.com> On Tue, 2 Jun 2020 12:59:52 +0800 Lianbo Jiang <lijiang@redhat.com> wrote: > Signature verification is an important security feature, to protect > system from being attacked with a kernel of unknown origin. Kexec > rebooting is a way to replace the running kernel, hence need be > secured carefully. I'm finding this changelog quite hard to understand, > In the current code of handling signature verification of kexec kernel, > the logic is very twisted. It mixes signature verification, IMA signature > appraising and kexec lockdown. > > If there is no KEXEC_SIG_FORCE, kexec kernel image doesn't have one of > signature, the supported crypto, and key, we don't think this is wrong, I think this is saying that in the absence of KEXEC_SIG_FORCE and if the signature/crypto/key are all incorrect, the kexec still succeeds, but it should not. > Unless kexec lockdown is executed. IMA is considered as another kind of > signature appraising method. > > If kexec kernel image has signature/crypto/key, it has to go through the > signature verification and pass. Otherwise it's seen as verification > failure, and won't be loaded. I don't know if this is describing the current situation or the post-patch situation. > Seems kexec kernel image with an unqualified signature is even worse than > those w/o signature at all, this sounds very unreasonable. E.g. If people > get a unsigned kernel to load, or a kernel signed with expired key, which > one is more dangerous? > > So, here, let's simplify the logic to improve code readability. If the > KEXEC_SIG_FORCE enabled or kexec lockdown enabled, signature verification > is mandated. Otherwise, we lift the bar for any kernel image. I think the whole thing needs a rewrite. Start out by fully describing the current situation. THen describe what is wrong with it, and why. Then describe the proposed change. Or something along these lines. The changelog should also make clear the end-user impact of the patch. In sufficient detail for others to decide which kernel version(s) should be patched. Your recommendations will also be valuable - which kernel version(s) do you think should be patched, and why?
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org> To: Lianbo Jiang <lijiang@redhat.com> Cc: jbohac@suse.cz, bhe@redhat.com, kexec@lists.infradead.org, jmorris@namei.org, mjg59@google.com, linux-kernel@vger.kernel.org, ebiederm@xmission.com, dyoung@redhat.com Subject: Re: [PATCH v2] kexec: Do not verify the signature without the lockdown or mandatory signature Date: Wed, 17 Jun 2020 12:37:31 -0700 [thread overview] Message-ID: <20200617123731.0dbb039a053a2ef610af59fb@linux-foundation.org> (raw) In-Reply-To: <20200602045952.27487-1-lijiang@redhat.com> On Tue, 2 Jun 2020 12:59:52 +0800 Lianbo Jiang <lijiang@redhat.com> wrote: > Signature verification is an important security feature, to protect > system from being attacked with a kernel of unknown origin. Kexec > rebooting is a way to replace the running kernel, hence need be > secured carefully. I'm finding this changelog quite hard to understand, > In the current code of handling signature verification of kexec kernel, > the logic is very twisted. It mixes signature verification, IMA signature > appraising and kexec lockdown. > > If there is no KEXEC_SIG_FORCE, kexec kernel image doesn't have one of > signature, the supported crypto, and key, we don't think this is wrong, I think this is saying that in the absence of KEXEC_SIG_FORCE and if the signature/crypto/key are all incorrect, the kexec still succeeds, but it should not. > Unless kexec lockdown is executed. IMA is considered as another kind of > signature appraising method. > > If kexec kernel image has signature/crypto/key, it has to go through the > signature verification and pass. Otherwise it's seen as verification > failure, and won't be loaded. I don't know if this is describing the current situation or the post-patch situation. > Seems kexec kernel image with an unqualified signature is even worse than > those w/o signature at all, this sounds very unreasonable. E.g. If people > get a unsigned kernel to load, or a kernel signed with expired key, which > one is more dangerous? > > So, here, let's simplify the logic to improve code readability. If the > KEXEC_SIG_FORCE enabled or kexec lockdown enabled, signature verification > is mandated. Otherwise, we lift the bar for any kernel image. I think the whole thing needs a rewrite. Start out by fully describing the current situation. THen describe what is wrong with it, and why. Then describe the proposed change. Or something along these lines. The changelog should also make clear the end-user impact of the patch. In sufficient detail for others to decide which kernel version(s) should be patched. Your recommendations will also be valuable - which kernel version(s) do you think should be patched, and why? _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2020-06-17 19:37 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-02 4:59 [PATCH v2] kexec: Do not verify the signature without the lockdown or mandatory signature Lianbo Jiang 2020-06-02 4:59 ` Lianbo Jiang 2020-06-02 11:45 ` Jiri Bohac 2020-06-02 11:45 ` Jiri Bohac 2020-06-03 9:56 ` Dave Young 2020-06-03 9:56 ` Dave Young 2020-06-08 7:40 ` Baoquan He 2020-06-08 7:40 ` Baoquan He 2020-06-10 8:21 ` lijiang 2020-06-10 8:21 ` lijiang 2020-06-17 19:37 ` Andrew Morton [this message] 2020-06-17 19:37 ` Andrew Morton 2020-06-18 9:58 ` lijiang 2020-06-18 9:58 ` lijiang
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=20200617123731.0dbb039a053a2ef610af59fb@linux-foundation.org \ --to=akpm@linux-foundation.org \ --cc=bhe@redhat.com \ --cc=dyoung@redhat.com \ --cc=ebiederm@xmission.com \ --cc=jbohac@suse.cz \ --cc=jmorris@namei.org \ --cc=kexec@lists.infradead.org \ --cc=lijiang@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mjg59@google.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.