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;
Date:   Fri, 17 Jun 2022 11:34:14 +0200
From:   Michal =?iso-8859-1?Q?Such=E1nek?= <msuchanek@suse.de>
To:     Mimi Zohar <zohar@linux.ibm.com>
Cc:     Coiby Xu <coxu@redhat.com>, kexec@lists.infradead.org,
        linux-arm-kernel@lists.infradead.org, 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
Message-ID: <20220617093414.GA4660@kitsune.suse.cz>
References: <20220512070123.29486-1-coxu@redhat.com>
 <20220512070123.29486-4-coxu@redhat.com>
 <e44bb6b11573838417b5d561173c27a1571c94b6.camel@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e44bb6b11573838417b5d561173c27a1571c94b6.camel@linux.ibm.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

Hello,

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.
> 
> 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.
> 
> > 
> > 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.
> 
> > 
> > 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.

It's definitely a fix

ea93102f32244e3f45c8b26260be77ed0cc1d16c v4.19-rc1 Fix kexec forbidding kernels signed with keys in the secondary keyring to boot
732b7b93d849f8a44886ead563dfb6adec7f4419 v5.0-rc1 arm64: kexec_file: add kernel signature verification support

the arm code does not reflect the preexisting use of the secondary keyring.

278311e417be60f7caef6fcb12bda4da2711ceff v5.1-rc1 kexec, KEYS: Make use of platform keyring for signature

This was added a bit later, indeed.

Cherry-picking the changes one by one to the arm code you can get
separate fixes tag for each change.

Replacing the arm code with the x86 code by code deduplication you get
whatever is the state of the art in the kernel in question. In 5.0 you
get the secondary keyring, and since 5.1 you also get the platform
keyring.

Nonetheless, it's a fix for the arm code which is deficient from the
very start.

Thanks

Michal