Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1063364imm; Wed, 15 Aug 2018 10:44:31 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzTLY8i++KEA3bSwsM0ix9hQxf1GiUCNCwpgvJGNMzo7YMI2A1r1JLr/skP9SGffgR1GY/o X-Received: by 2002:a62:129a:: with SMTP id 26-v6mr28794967pfs.102.1534355071215; Wed, 15 Aug 2018 10:44:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534355071; cv=none; d=google.com; s=arc-20160816; b=TMZcPZoV44zELyTLfVgAmF1Te96o1hN4R2NNqP54d0E4aGLh9K2HhtppBAhmcvrq+Q NqN/wgg5ipiCJ20Y3PDP9FIMzNrcHmMwLBkxZ80VsfXJLajGZh+xznPaocM7PBFjf/62 KgkL8x/MzDXbsPb/uGMKJwVTZUaMkC8QOFA4DJ1o0hMGSnd3KrntQzpFAPcztqjNrRy3 q9bGoH3tc4xbDyv/ofyXVnui5u0UtR7aaHpLJnZEiNAbMzM+cEjJfZn/1Rr0zF03raut 3B9+yjlCo80koJakVr+p3Vw5tsN4WqHEfcEaj1lwbPGlDCDsD+jwxs3r88z+mUs1gtaa I6ZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=uMYHRApIvZeFQAIjN1HdhrLjHIjggV2cHCUVMJS3kEI=; b=h8Pe0JGqWXfyNaKACTL1TdUEcSrWQLW1gaSGYLCJMSOUMfaLcpz4+vY+eumPiOOv5v OYz8hHpOVa+h5foWyDfd/7h/iBOGYp2RiJuQkXdT+0brHmcPcSvimbuJBlPHBJxOYSWl /s/gHYxyMsMYdk8YGRV4SxPaWebJDBhRyCxZI4k/Uei5digHXMf9vF6wQwN1PWaM/S9f eXtcESJ4rEO+/KEeYqYps91Og/ONOIeYQ6Ym7I1pI1IUHmqRHttmtH4ifK6FEy5kyxUY 5bVXp+qrAretsn00jJSrBepMEYsBMvchsA+Zd9hrhF5wdyJgy+CUJoGtT+8R/ze8L7ka +C+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c4-v6si25197333pfa.285.2018.08.15.10.44.15; Wed, 15 Aug 2018 10:44:31 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729516AbeHOUfz (ORCPT + 99 others); Wed, 15 Aug 2018 16:35:55 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:46940 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729363AbeHOUfy (ORCPT ); Wed, 15 Aug 2018 16:35:54 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1D8877D84D; Wed, 15 Aug 2018 17:42:48 +0000 (UTC) Received: from horse.redhat.com (unknown [10.18.25.234]) by smtp.corp.redhat.com (Postfix) with ESMTP id 500842026D7E; Wed, 15 Aug 2018 17:42:47 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 173C822425E; Wed, 15 Aug 2018 13:42:47 -0400 (EDT) Date: Wed, 15 Aug 2018 13:42:47 -0400 From: Vivek Goyal To: Yannik Sembritzki Cc: Linus Torvalds , David Howells , Thomas Gleixner , Ingo Molnar , Peter Anvin , the arch/x86 maintainers , Linux Kernel Mailing List , Dave Young , Baoquan He , "Justin M. Forbes" Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot Message-ID: <20180815174247.GB29541@redhat.com> References: <20180815100053.13609-1-yannik@sembritzki.me> <654fbafb-69da-cd9a-b176-7b03401e71c5@sembritzki.me> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <654fbafb-69da-cd9a-b176-7b03401e71c5@sembritzki.me> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 15 Aug 2018 17:42:48 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 15 Aug 2018 17:42:48 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'vgoyal@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote: > Would this be okay? [ CC dave young, Baoquan, Justin Forbes] Hi Yannik, I am reading that bug and wondering that what broke it. It used to work, so some change broke it. Justin said that we have been signing fedora kernels with fedora keys so looks like no change there. Previously, I think all the keys used to go in system keyring and it used to work. Is it somehow because of split in builtin keyring and secondary system keyring. Could it be that fedora key used to show up in system keyring previously and it worked but now it shows up in secondary system keyring and by default we don't use keys from that keyring for signature verification? Thanks Vivek > > diff --git a/arch/x86/kernel/kexec-bzimage64.c > b/arch/x86/kernel/kexec-bzimage64.c > index 7326078e..2ba47e24 100644 > --- a/arch/x86/kernel/kexec-bzimage64.c > +++ b/arch/x86/kernel/kexec-bzimage64.c > @@ -41,6 +41,9 @@ > ?#define MIN_KERNEL_LOAD_ADDR?? 0x100000 > ?#define MIN_INITRD_LOAD_ADDR?? 0x1000000 > ? > +// Allow both builtin trusted keys and secondary trusted keys > +#define TRUST_FULL_KEYRING???? (void *)1UL > + > ?/* > ? * This is a place holder for all boot loader specific data structure which > ? * gets allocated in one call but gets freed much later during cleanup > @@ -532,7 +535,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, > +????????????????????????????????????? TRUST_FULL_KEYRING, > ?????????????????????????????????????? VERIFYING_KEXEC_PE_SIGNATURE); > ?} > ?#endif > -- > > On 15.08.2018 18:54, Linus Torvalds wrote: > > 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 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 > >> >