Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20180815100053.13609-1-yannik@sembritzki.me>
In-Reply-To: <20180815100053.13609-1-yannik@sembritzki.me>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed, 15 Aug 2018 09:54:34 -0700
Message-ID: <CA+55aFx2goMXj7rQg-qx-puiiWYJmkDMU1xniWEu6ikDBNgfdQ@mail.gmail.com>
Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom platform
 keys to boot
To:     yannik@sembritzki.me, David Howells <dhowells@redhat.com>,
        Vivek Goyal <vgoyal@redhat.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Peter Anvin <hpa@zytor.com>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

This needs more people involved, and at least a sign-off.

It looks ok, but I think we need a #define for the magical (void *)1UL
thing. I see the use in verify_pkcs7_signature(), but still.

              Linus


On Wed, Aug 15, 2018 at 3:11 AM Yannik Sembritzki <yannik@sembritzki.me> wrote:
>
> ---
>  arch/x86/kernel/kexec-bzimage64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
> index 7326078e..eaaa125d 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -532,7 +532,7 @@ static int bzImage64_cleanup(void *loader_data)
>  static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len)
>  {
>         return verify_pefile_signature(kernel, kernel_len,
> -                                      NULL,
> +                                      (void *)1UL,
>                                        VERIFYING_KEXEC_PE_SIGNATURE);
>  }
>  #endif
> --
> 2.17.1
>
> The exact scenario under which this issue occurs is described here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1554113
>