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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 0B2F5C433F5 for ; Fri, 20 May 2022 17:06:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZG6ve8jsP1GykoHrr5AW4LAg2CxAh5+q9/5HJNOfI0E=; b=R+ajKEM8p6p9dR u4QRC7E2QHujjWImUuulN8IAA+j7S7X571ZfZC0GM50GPQbAYxqYICLcmBwYlB4NunLN7g+kvUb08 szbCQBk9oEUyxf9znjZhVi448nCN2UahNyh8x0LCWLIuWnTPyFiOBEVB8bCWqVxVvjkFpew3MgUd+ iZ/hNJ/lIQoJlrsexzjWakXzDCaoVZ0+pkBATvBjAwN0ldS6rGpiISEBhdHaGlyetAdA+OFxPHaBo nQYyJqE8T8XjdbsBsFy6JtMejj9mVDl6OHva5D1Y/tKKnb6BLg+GzWCYhM3BYk+n3/uI3e+LyDciA c0ORwDWHezexIJ+L7eRQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ns63k-00Dpz5-Kh; Fri, 20 May 2022 17:05:04 +0000 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ns63h-00Dpy5-5L; Fri, 20 May 2022 17:05:02 +0000 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24KFTQVM017124; Fri, 20 May 2022 17:04:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=dpaivS1YrZE75REpcCBlePAzlXbn1KXc7QdMP7gRDv4=; b=Xa6lkJcAvUet7LGRDuGUzFA4R48tDzGXdTeDGlpDtn6K1Wy4HaLUqzB6mTtoR0DTYR/C bSKD5ktiBFnBIzltBthMbKZ9y//WOji+A1SE5H6xXEdT0vnxPbwnEklJfp37pjpernlr vTpEzJVb5bPER8RGVuXm74cFf8+qf0Jk30UZVz5AUcrkzxxme4pq6iNeC2vw+MIMzNSg 03vlodgdR55pspCf1XGXUUXMhwTvI1zV8WjEfiY3jk9XkU5PltDbMzLNFeW7Basl7G2e Rw0ybz2h4JDkK0zmxuu0Xt2JpwEKdDzMOukC8dmZuqbAhEiRGq25f180/caTm4L8FaZt 6Q== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3g6b7edj4w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 May 2022 17:04:54 +0000 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 24KFkrDj015706; Fri, 20 May 2022 17:04:54 GMT Received: from ppma04fra.de.ibm.com (6a.4a.5195.ip4.static.sl-reverse.com [149.81.74.106]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3g6b7edj3q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 May 2022 17:04:54 +0000 Received: from pps.filterd (ppma04fra.de.ibm.com [127.0.0.1]) by ppma04fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 24KH2wIr023596; Fri, 20 May 2022 17:04:51 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma04fra.de.ibm.com with ESMTP id 3g2428yep8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 May 2022 17:04:51 +0000 Received: from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 24KH4nFM43516334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 May 2022 17:04:49 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5083342041; Fri, 20 May 2022 17:04:49 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 226394203F; Fri, 20 May 2022 17:04:48 +0000 (GMT) Received: from sig-9-65-82-251.ibm.com (unknown [9.65.82.251]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 20 May 2022 17:04:48 +0000 (GMT) Message-ID: Subject: Re: [PATCH v8 0/4] use more system keyrings to verify arm64 and s390 kexec kernel image signature From: Mimi Zohar To: Coiby Xu , kexec@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org, Michal Suchanek , Baoquan He , Dave Young , Will Deacon , "Eric W . Biederman" , Chun-Yi Lee Date: Fri, 20 May 2022 13:04:47 -0400 In-Reply-To: <20220512070123.29486-1-coxu@redhat.com> References: <20220512070123.29486-1-coxu@redhat.com> X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-GUID: fM1-zwpNrN7NNh5s9ZCscvJPTN213Jsr X-Proofpoint-ORIG-GUID: 3uoKu7sgEQBMBHe5n5hYuP8U3nUmsEk9 X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-20_05,2022-05-20_02,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0 suspectscore=0 lowpriorityscore=0 malwarescore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 bulkscore=0 adultscore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205200107 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220520_100501_262619_63259B93 X-CRM114-Status: GOOD ( 30.63 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Coiby, On Thu, 2022-05-12 at 15:01 +0800, Coiby Xu wrote: The cover letter should start out with an overall problem description and then continue with the specifics. In this case each of the arch's use different keyrings to validate the kexec kernel image signature. I would continue with saying the MOK keys were originally loaded onto the .platform keyring with the other EFI keys, but recently with the new .machine keyring that changed. The purpose of this patch set is a generic solution for the different archs. > 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 arm64 uses > only the primary keyring i.e. the .builtin_trusted_keys keyring that > contains only kernel built-in keys to verify the kexec kernel image. MOK > keys are loaded into the .platform keyring or/and .machine keyring. The > .machine keyring is linked to the secondary keyring i.e. > .secondary_trusted_keys keyring when the end-user chooses to trust MOK > keys. The platform keyring is exclusively used for kexec kernel image > verification and .secondary_trusted_keys together with > .builtin_trusted_keys are the system trusted keyrings. So obviously > there is no reason to not use .secondary_trusted_keys or .platform > keyring for kernel image signature verification. Both the ".platform" and ".machine" keyring are linked to the ".secondary_trusted_keys" keyring. The root of trust for these keyrings are very different. Instead of saying "So obviously there is no reason to not use .secondary_trusted_keys" it would be more beneficial to describe the root of trusts, allowing others to draw their own conclusions for their usecase. thanks, Mimi > > Similarly, s390 only uses platform keyring for kernel image signature > verification and built-in keys and secondary keyring are not used. > > This patch set allows arm64 and s390 to use more system keyrings > including the .secondary_trusted_keys and .platform keyring to verify > kexec kernel image signature as x86 does. > > The 3rd arm64 patch depends on the first two patches. The 4th s390 patch > can be applied independently. > v8: > - drop "Cc: stable@vger.kernel.org" for the first two prerequisite > patches [Baoquan] > > v7: > - drop the Fixes tag for the 2nd patch and add patch prerequisites > [Baoquan] > - improve cover letter > > v6: > - integrate the first three patches of "[PATCH 0/4] Unifrom keyring > support across architectures and functions" from Michal [1] > - improve commit message [Baoquan, Michal] > - directly assign kexec_kernel_verify_pe_sig to > kexec_file_ops->verify_sig [Michal] > > v5: > - improve commit message [Baoquan] > > v4: > - fix commit reference format issue and other checkpatch.pl warnings [Baoquan] > > v3: > - s/arch_kexec_kernel_verify_pe_sig/kexec_kernel_verify_pe_sig [Eric] > - clean up arch_kexec_kernel_verify_sig [Eric] > > v2: > - only x86_64 and arm64 need to enable PE file signature check [Dave] > > [1] https://lore.kernel.org/lkml/cover.1644953683.git.msuchanek@suse.de/ > > Coiby Xu (3): > kexec: clean up arch_kexec_kernel_verify_sig > kexec, KEYS: make the code in bzImage64_verify_sig generic > arm64: kexec_file: use more system keyrings to verify kernel image > signature > > Michal Suchanek (1): > kexec, KEYS, s390: Make use of built-in and secondary keyring for > signature verification > > arch/arm64/kernel/kexec_image.c | 11 +----- > arch/s390/kernel/machine_kexec_file.c | 18 +++++++--- > arch/x86/kernel/kexec-bzimage64.c | 20 +---------- > include/linux/kexec.h | 7 ++-- > kernel/kexec_file.c | 51 ++++++++++++++++----------- > 5 files changed, 50 insertions(+), 57 deletions(-) > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel