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 8F734C433F5 for ; Fri, 27 May 2022 16:47:53 +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=odHH4hKr1tMQvzZLahjhKrCSQXpkcnRllowD5ncsH1E=; b=Vqq9kWetz/tVWQ tZHisf4uDV79uSvQRW6WVzracX6rt8QOXvexyf19qCiPnlWnTIPKwkww+Gy4vlJ8t3xO18/eGVwX0 DIdCyQK5hpVK6F2qSzve1Oi1w5xjiFqZvgTRL3JTat0svuUu77u9RBiIKzv5cLNXVDbAKwSG6s48P ZFmVKt++/iKdouJuWN5i8FCD2LHiBrbTJPFzG5aCsqh54Q7I0lUAiA9VErzEBWyTM/VjO4J50RGha hZCD3xGAcbbTi1yz9sUXlFFc3hAIqeMVPMdhHP1ouKFP64YoKK9VWaGwjuOBytj8A9LQSB5PC5oGb n/znnZJchDI1Bmtg6lqg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nud6N-000ZRG-3s; Fri, 27 May 2022 16:46:15 +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 1nud6J-000ZQG-BA; Fri, 27 May 2022 16:46:13 +0000 Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24RG6FAu019971; Fri, 27 May 2022 16:46:02 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 : mime-version : content-transfer-encoding; s=pp1; bh=2rViko80Jaey8oSBszRMh+VaBg/TuBSzJbrBQgbR81w=; b=ORzD2jOHeru44VjVy+Zy2BXpgl8N49Ze4H3kR6OMdmCAohJV5k4w+nIgQZWxRjLS3dzW ZdjIKD51yBXoA344d6eXYJoI1QDtKhoQlZ/Df9d+DPmB+a7/hSkxTWUJUCAXfjPfyyn6 BYWepBWVAkCSEp2yZgF5o+h1/JV9rQxjOFPsuEfOX/YTJPldwQ3E5cYJ5dF1Ajdboe0E 9xTto30FZpouRJRIc0Kq8f7bNtWemNCtoSQ5Ve24qByURQdd9/yFmAJB9mFegRaAoHcD v2iZN5H36II02FOTww+4a0QCOr0PRinr8SqNjPkGuCBjTE/LqXMAZWP4k/TE/TNLuJL1 tw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gb1q38vm2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 May 2022 16:46:02 +0000 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 24RGd6k9016210; Fri, 27 May 2022 16:46:01 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 3gb1q38vk0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 May 2022 16:46:01 +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 24RGbth1006024; Fri, 27 May 2022 16:45:59 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma04fra.de.ibm.com with ESMTP id 3g94g3bacf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 May 2022 16:45:58 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 24RGjuva22086006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 27 May 2022 16:45:56 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A38F5A404D; Fri, 27 May 2022 16:45:56 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 823E0A4040; Fri, 27 May 2022 16:45:55 +0000 (GMT) Received: from sig-9-65-91-114.ibm.com (unknown [9.65.91.114]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 27 May 2022 16:45:55 +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 Cc: kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Michal Suchanek , Baoquan He , Dave Young , Will Deacon , "Eric W . Biederman" , Chun-Yi Lee Date: Fri, 27 May 2022 12:45:54 -0400 In-Reply-To: <20220527134315.afnuszqbfqkpnxpv@Rk> References: <20220512070123.29486-1-coxu@redhat.com> <20220525095957.vvref4yeaidd5iww@Rk> <20220527134315.afnuszqbfqkpnxpv@Rk> X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: -zzfMrBrt0NXDD47DV3n35vf5sFc_VBr X-Proofpoint-ORIG-GUID: 3-opHbVDqEvvrZfBf4LPgmTlpxORNocP 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-27_04,2022-05-27_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 adultscore=0 suspectscore=0 bulkscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2205270080 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220527_094611_670854_D1763599 X-CRM114-Status: GOOD ( 34.34 ) 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 On Fri, 2022-05-27 at 21:43 +0800, Coiby Xu wrote: > Hi Mini, Hi Coiby, > new cover letter here to collect new feedback from you thus we > can avoid unnecessary rounds of patch set. Agreed. Much better. Just a couple of nits. > Currently when loading a kernel image via the kexec_file_load() system > call, x86 can make use of three keyrings i.e. the .builtin_trusted_keys, > .secondary_trusted_keys and .platform keyrings to verify signature. Either "a signature" or "signatures". > However, arm64 and s390 can only use the .builtin_trusted_keys and > .platform keyring respectively. For example, one resulting problem is > kexec'ing a kernel image would be rejected with the error "Lockdown: > kexec: kexec of unsigned images is restricted; see man > kernel_lockdown.7". > > This patch set enables arm64 and s390 to make use of the same keyrings > as x86 to very the signature kexec'ed kernel image. Fix "very". Perhaps "verify the kexec'ed kernel image signature". > > The recently introduced .machine keyring impacts the roots of trust by > linking the .machine keyring to the .secondary keyring. The roots of > trust of different keyring are described as follows, > "of ... keyring" -> "for the ... keyrings" > .builtin_trusted_keys: > > Keys may be built into the kernel during build or inserted into memory > reserved for keys post build. The root of trust is the kernel build i.e. > a Linux distribution vendor. On a physical system in a secure boot > environment, this trust is rooted in hardware. Please look at my response to your question below. > > .machine: > > If the end-users choose to trust the keys provided by first-stage UEFI > bootloader shim i.e. Machine Owner Keys (MOK keys), the keys will be > added to this keyring and this keyring is linked to the Grammatically "and this" needs to be fixed. > .secondary_trusted_keys keyring as same as the .builtin_trusted_keys > keyring. Shim has built-in keys from a Linux distribution or the > end-users-enrolled keys. So the root of trust of this keyring is either > a Linux distribution vendor or the end-users. > > .secondary_trusted_keys: > > Certificates signed by keys on the .builtin_trusted_keys, .machine, or > existing keys on the .secondary_trusted_keys keryings may be loaded > onto the .secondary_trusted_keys keyring. This establishes a signature > chain of trust based on keys loaded on either the .builtin_trusted_keys > or .machine keyrings, if configured and enabled. > > .platform: > > The .platform keyring consist of UEFI db and MOK keys which are used by > shim to verify the first boot kernel's image signature. If end-users > choose to trust MOK keys and the kernel has the .machine keyring > enabled, the .platform keyring only consists of UEFI db keys since the > MOK keys are added to the .machine keyring instead. Because the > end-users could also enroll there own MOK keys, the root of trust could "there" -> "their" > be hardware or the end-users. It's always "hardware". "or" -> "and"? > >> > >> The root of trusts of the keys in the %.builtin_trusted_keys and > >> secondary_trusted_keys keyring is a Linux distribution vendor. > > > >The root of trust for each keyring should be described separately. > > > >.builtin_trusted_keys: > > > >For example, > > > >Keys may be built into the kernel during build or inserted into memory > >reserved for keys post build. In both of these cases, trust is based > >on verification of the kernel image signature. > > Correct me if I'm wrong, without secure boot, there is no verification > of the kernel image signature so the root of trust should be trust on > the kernel builder. No, basing the signature verification on secure boot could not have been upstreamed. IMA is based on policy, regardeless of the secure boot mode. A builtin policy may be specified on the boot command line, but should be replaced with a more constrained custom policy [1]. Unlike the builtin policy rules, the architecture specific rules are persistent[2]. The architecture specific rules are normally tied to the secure boot modes. On OpenPOWER, the architecture specific "measure" rules are dependent on the trusted boot mode. The current IMA policy rules can be viewed by cat'ing /ima/policy. [1] The builtin policies are not LSM aware. The policy rules need to be constrained to avoid integrity violations. [2] arch specific policy rules: security/integrity/ima/ima_efi.c, arch/powerpc/kernel/ima_arch.c thanks, Mimi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mimi Zohar Date: Fri, 27 May 2022 12:45:54 -0400 Subject: [PATCH v8 0/4] use more system keyrings to verify arm64 and s390 kexec kernel image signature In-Reply-To: <20220527134315.afnuszqbfqkpnxpv@Rk> References: <20220512070123.29486-1-coxu@redhat.com> <20220525095957.vvref4yeaidd5iww@Rk> <20220527134315.afnuszqbfqkpnxpv@Rk> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kexec@lists.infradead.org On Fri, 2022-05-27 at 21:43 +0800, Coiby Xu wrote: > Hi Mini, Hi Coiby, > new cover letter here to collect new feedback from you thus we > can avoid unnecessary rounds of patch set. Agreed. Much better. Just a couple of nits. > Currently when loading a kernel image via the kexec_file_load() system > call, x86 can make use of three keyrings i.e. the .builtin_trusted_keys, > .secondary_trusted_keys and .platform keyrings to verify signature. Either "a signature" or "signatures". > However, arm64 and s390 can only use the .builtin_trusted_keys and > .platform keyring respectively. For example, one resulting problem is > kexec'ing a kernel image would be rejected with the error "Lockdown: > kexec: kexec of unsigned images is restricted; see man > kernel_lockdown.7". > > This patch set enables arm64 and s390 to make use of the same keyrings > as x86 to very the signature kexec'ed kernel image. Fix "very". Perhaps "verify the kexec'ed kernel image signature". > > The recently introduced .machine keyring impacts the roots of trust by > linking the .machine keyring to the .secondary keyring. The roots of > trust of different keyring are described as follows, > "of ... keyring" -> "for the ... keyrings" > .builtin_trusted_keys: > > Keys may be built into the kernel during build or inserted into memory > reserved for keys post build. The root of trust is the kernel build i.e. > a Linux distribution vendor. On a physical system in a secure boot > environment, this trust is rooted in hardware. Please look at my response to your question below. > > .machine: > > If the end-users choose to trust the keys provided by first-stage UEFI > bootloader shim i.e. Machine Owner Keys (MOK keys), the keys will be > added to this keyring and this keyring is linked to the Grammatically "and this" needs to be fixed. > .secondary_trusted_keys keyring as same as the .builtin_trusted_keys > keyring. Shim has built-in keys from a Linux distribution or the > end-users-enrolled keys. So the root of trust of this keyring is either > a Linux distribution vendor or the end-users. > > .secondary_trusted_keys: > > Certificates signed by keys on the .builtin_trusted_keys, .machine, or > existing keys on the .secondary_trusted_keys keryings may be loaded > onto the .secondary_trusted_keys keyring. This establishes a signature > chain of trust based on keys loaded on either the .builtin_trusted_keys > or .machine keyrings, if configured and enabled. > > .platform: > > The .platform keyring consist of UEFI db and MOK keys which are used by > shim to verify the first boot kernel's image signature. If end-users > choose to trust MOK keys and the kernel has the .machine keyring > enabled, the .platform keyring only consists of UEFI db keys since the > MOK keys are added to the .machine keyring instead. Because the > end-users could also enroll there own MOK keys, the root of trust could "there" -> "their" > be hardware or the end-users. It's always "hardware". "or" -> "and"? > >> > >> The root of trusts of the keys in the %.builtin_trusted_keys and > >> secondary_trusted_keys keyring is a Linux distribution vendor. > > > >The root of trust for each keyring should be described separately. > > > >.builtin_trusted_keys: > > > >For example, > > > >Keys may be built into the kernel during build or inserted into memory > >reserved for keys post build. In both of these cases, trust is based > >on verification of the kernel image signature. > > Correct me if I'm wrong, without secure boot, there is no verification > of the kernel image signature so the root of trust should be trust on > the kernel builder. No, basing the signature verification on secure boot could not have been upstreamed. IMA is based on policy, regardeless of the secure boot mode. A builtin policy may be specified on the boot command line, but should be replaced with a more constrained custom policy [1]. Unlike the builtin policy rules, the architecture specific rules are persistent[2]. The architecture specific rules are normally tied to the secure boot modes. On OpenPOWER, the architecture specific "measure" rules are dependent on the trusted boot mode. The current IMA policy rules can be viewed by cat'ing /ima/policy. [1] The builtin policies are not LSM aware. The policy rules need to be constrained to avoid integrity violations. [2] arch specific policy rules: security/integrity/ima/ima_efi.c, arch/powerpc/kernel/ima_arch.c thanks, Mimi