Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <bd1d2f66bffb25fd80b2dd2464f8cda24f68c249.camel@linux.ibm.com>
Subject: Re: [PATCH v3 1/2] lockdown: kexec_file: prevent unsigned kernel
 image when KEXEC_SIG not enabled
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Coiby Xu <coxu@redhat.com>, kexec@lists.infradead.org
Cc:     Matthew Garrett <mjg59@srcf.ucam.org>, Jiri Bohac <jbohac@suse.cz>,
        David Howells <dhowells@redhat.com>,
        linux-integrity@vger.kernel.org,
        Eric Biederman <ebiederm@xmission.com>,
        Matthew Garrett <mjg59@google.com>,
        James Morris <jmorris@namei.org>,
        open list <linux-kernel@vger.kernel.org>
Date:   Tue, 03 Jan 2023 09:42:26 -0500
In-Reply-To: <20221230065850.897967-1-coxu@redhat.com>
References: <20221230065850.897967-1-coxu@redhat.com>
Content-Type: text/plain; charset="ISO-8859-15"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Coiby,

On Fri, 2022-12-30 at 14:58 +0800, Coiby Xu wrote:
> A kernel builder may not enable KEXEC_SIG and some architectures like
> ppc64 simply don't have KEXEC_SIG. In these cases, unless both
> IMA_ARCH_POLICY and secure boot also enabled, lockdown doesn't prevent
> unsigned kernel image from being kexec'ed via the kexec_file_load
> syscall whereas it could prevent one via the kexec_load syscall. Mandate
> signature verification for those cases.

The phrase "unless both IMA_ARCH_POLICY and secure boot also enabled"
doesn't reflect the code.  IMA could contain a custom policy rule which
requires the kexec kernel image signature verification as well.  Refer
to the comment now in mandate_signature_verification().

thanks,

Mimi