From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 25EE4C32771 for ; Sat, 24 Sep 2022 11:56:22 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4MZSCm56cJz3dqN for ; Sat, 24 Sep 2022 21:56:20 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=YGEJD2Fn; dkim=fail reason="signature verification failed" header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=nzWakO9k; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=suse.de (client-ip=2001:67c:2178:6::1d; helo=smtp-out2.suse.de; envelope-from=msuchanek@suse.de; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=YGEJD2Fn; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=nzWakO9k; dkim-atps=neutral Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4MZSBz23V4z3bhy for ; Sat, 24 Sep 2022 21:55:38 +1000 (AEST) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id B8C341F901; Sat, 24 Sep 2022 11:55:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1664020527; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=79a8D2Ac7u6BFH11MTZyHbw/7iUCqU/F8iDUx62qwgI=; b=YGEJD2FnZ9chHMjXQmq8tdyuK381YZ49y8Fwu6+QAESAODmoRFO6jaBrLA+UNJOD74ZXgU hRqDPRKM+aBa9zhQ/rw0ACFs90S1D1jpjzgf4mysd+w97EHzqCfYBn+ncLZekTVmq7ELnj 5l7eXJMwaYodicCd6KkAfOLiw6C7qbc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1664020527; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=79a8D2Ac7u6BFH11MTZyHbw/7iUCqU/F8iDUx62qwgI=; b=nzWakO9kDNhf03FBvsJdphgf1O0ls25eU8ml4O7M7wQRDydBm7NdZbDWeYkgsiPNOJC78F Y/Fua/kXHZSDahCg== Received: from kitsune.suse.cz (kitsune.suse.cz [10.100.12.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id D8EC22C16E; Sat, 24 Sep 2022 11:55:24 +0000 (UTC) Date: Sat, 24 Sep 2022 13:55:23 +0200 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Greg Kroah-Hartman Subject: Re: [PATCH 5.15 0/6] arm64: kexec_file: use more system keyrings to verify kernel image signature + dependencies Message-ID: <20220924115523.GZ28810@kitsune.suse.cz> References: <20220924094521.GY28810@kitsune.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dave Hansen , Alexander Egorenkov , keyrings@vger.kernel.org, Paul Mackerras , "H. Peter Anvin" , Alexander Gordeev , Will Deacon , Sasha Levin , "open list:S390" , Coiby Xu , Baoquan He , AKASHI Takahiro , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , Christian Borntraeger , Ingo Molnar , Catalin Marinas , "Naveen N. Rao" , Eric Biederman , Vasily Gorbik , Heiko Carstens , Borislav Petkov , Mimi Zohar , Thomas Gleixner , "moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)" , Philipp Rudo , "open list:KEXEC" , linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux-security-module@vger.kernel.org, James Morse , Sven Schnelle , Andrew Morton , "open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote: > On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote: > > On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote: > > > > Hello, > > > > > > > > this is backport of commit 0d519cadf751 > > > > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > > > > to table 5.15 tree including the preparatory patches. > > > > > > This feels to me like a new feature for arm64, one that has never worked > > > before and you are just making it feature-parity with x86, right? > > > > > > Or is this a regression fix somewhere? Why is this needed in 5.15.y and > > > why can't people who need this new feature just use a newer kernel > > > version (5.19?) > > > > It's half-broken implementation of the kexec kernel verification. At the time > > it was implemented for arm64 we had the platform and secondary keyrings > > and x86 was using them but on arm64 the initial implementation ignores > > them. > > Ok, so it's something that never worked. Adding support to get it to > work doesn't really fall into the stable kernel rules, right? Not sure. It was defective, not using the facilities available at the time correctly. Which translates to kernels that can be kexec'd on x86 failing to kexec on arm64 without any explanation (signed with same key, built for the appropriate arch). > Again, what's wrong with 5.19 for anyone who wants this? Who does want > this? Not sure, really. The final patch was repeatedly backported to stable and failed to build because the prerequisites were missing. So this is a backport that includes the prerequisites for it to build. If nobody wanted this why is it repeatedly backported generating the failure messages? Thanks Michal