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 26C5BC433FE for ; Wed, 25 May 2022 13:32:17 +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=TMqUH4XSRanGjchDNLo2zLCUsCeHD86u2uofwRZ2KQ8=; b=LG526H6Y8FYFm4 9jQ/KVSHD4vqZ3+uoTIOTbnSjeMApSkFlZJIpgZA91qkPam/CtDY3fX7YPymrNVxH/5GH3OI4Xyhh vqQkhMpxx3woE8EuELgbWzmSpmz6ygSqqwY3+WSbK4l4RIxxZaiI7EMcmF2REDq3JYuwJ5Gd3kmVG wQYkXEXaIe7MPNk3j9iP54a/oQ+k/b99OedVOXpUAEfmBRfmTLFvHhx8bmcDLr2m855N6fSRPdCvB NzL85RKMz4bWLRRUoDDZctimS4B5RJX6X5UZHSBdVIHsbTFeBCgJaU7DYf9/hp+vbLX3vkY2n/Jjk 5vTeUdADB38Saqw0H1Sw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ntr6M-00BErd-KC; Wed, 25 May 2022 13:31:02 +0000 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5] helo=mx0a-001b2d01.pphosted.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ntr6J-00BEql-3d; Wed, 25 May 2022 13:31:01 +0000 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24PC4I9W024352; Wed, 25 May 2022 13:30:46 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=g8cizJUFKDvLoC+QYffMnhYaguuivWdEDxqZeO0PQGA=; b=Dba8toA2MHktXPt39bjjYRNTwiFc84xANxJj5p3EJxZA1QLsbwZo5Q+qYoDlteggWecK 9FvWlUk7VhP38S+o9cDDfeADrNeRyuMLCsfdp2Abd4jfJjSeUKRXk6bXDwKvnxCGjYhA EBu9XnBr2DXJiMxN/XRwlDtncLR3xJALCFnYIltnTlmACWJQu662c/ACFlZe8mSlqi9O UL8btHNYbck3QVaKx9W0sq9udcMnVik1/DbSU5wK3m3gXNqcO8Zrg9CGmf9gOoAUzQdD uAdX33PAhh5I/YzYxxqTc1nW8I7XUk9APHvfTGB7SCizVH0oQD55y5ulbuzN8kKMLuRV yA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3g9h91d36r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 May 2022 13:30:46 +0000 Received: from m0098413.ppops.net (m0098413.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 24PDFlQD019950; Wed, 25 May 2022 13:30:45 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3g9h91d360-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 May 2022 13:30:45 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 24PDEPga002536; Wed, 25 May 2022 13:30:44 GMT Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by ppma06ams.nl.ibm.com with ESMTP id 3g93uw97hh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 May 2022 13:30:43 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 24PDUfBP20054284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 May 2022 13:30:41 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B70B75204F; Wed, 25 May 2022 13:30:41 +0000 (GMT) Received: from sig-9-65-91-147.ibm.com (unknown [9.65.91.147]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 9BF435204E; Wed, 25 May 2022 13:30:40 +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: Wed, 25 May 2022 09:30:40 -0400 In-Reply-To: <20220525095957.vvref4yeaidd5iww@Rk> References: <20220512070123.29486-1-coxu@redhat.com> <20220525095957.vvref4yeaidd5iww@Rk> X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: tgBr1e7Ia_KJk0Tf0oRsr9H8Z2OaAtNa X-Proofpoint-GUID: Kt-pp1OGKhiMKpLMdkLZKMu_ViFY9mf- 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-25_03,2022-05-25_02,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 impostorscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 suspectscore=0 malwarescore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2205250067 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220525_063059_331117_264D78D9 X-CRM114-Status: GOOD ( 49.84 ) 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 Wed, 2022-05-25 at 17:59 +0800, Coiby Xu wrote: > Hi Mimi, > > On Fri, May 20, 2022 at 01:04:47PM -0400, Mimi Zohar wrote: > >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 > > Thanks for the suggestion! I will start with an overall problem > description in next version. For me, the bigger problem is arm kexec > can't make use of .secondary_trusted_keys or .platform to verify kernel > image signature. The by-product of the solution is it also helps > address the problem of inconsistent usage of keyrings by kexec between > different arches. > > >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. > > It seems I lack some background knowledge that makes me fail to > appreciate what change the new .machine keyring brings to kexec. As far > as I can understand, the new .machine keyring doesn't seem to change > much about kexec kernel image signature verification. kexec should be > able to use MOK keys to verify signature regardless of the keys being > loaded into .platform keyring or into the new .machine keyring. Because > the MOK keys have already be used to verify the 1st booting kernel's > image signature. To me, the significance of the new .machine keyring is > the end-users-enrolled keys can be also used to verify kernel modules > (the end users can also add his key to the .secondary_trusted_keys > keyring but the key needs to vouched by any existing key from the > .builtin_trusted_keys or .secondary_trusted_keys which is nearly > impossible). "the significance of the new .machine keyring is the end-users-enrolled keys can be also used to verify kernel modules" correct. So any key stored in MOK and loaded onto the .machine keyring, could also then be used to verify the kexec'ed kernel image signature as well. > > > > >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. > > I don't find any code that links the .platform keyring to the > .secondary_trusted_keys keyring and one [1] of your replies to "[PATCH > 4/4] module, KEYS: Make use of platform keyring for signature > verification" is as follows, > "Permission for loading the pre-OS keys onto the 'platform' keyring and > using them is limited to verifying the kexec kernel image, nothing > else." Right, that should have been, "Both the .builtin_trusted_keys and .machine keyrings are linked ..." > > [1] https://lore.kernel.org/linux-arm-kernel/3e39412657a4b0839bcf38544d591959e89877b8.camel@linux.ibm.com/ > > >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. Linking the .machine keyring to the .secondary keyring impacts the root(s) of trust. > > Thanks for the suggestion! I'll add the following text in v9, do it > looks good to you? > > 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. On a physical system in a secure boot environment, this trust is rooted in HW. .machine: < explanation > .secondary_trusted_keys: For example, 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 < explanation > thanks, Mimi > The > .platform keyring could have both UEFI db keys and MOK keys or only UEFI > db keys. And the .machine keyring only have MOK keys. The root trust of > UEFI db keys is UEFI Platform Key which is shipped by an UEFI firmware > vendor. The root trust of MOK keys is a Linux distribution vendor (shim > has built-in MOK key) and the end user could also be another root of > trust if he/she enrolls his own key. > > The %.builtin_trusted_keys keyring consists of the trustable keys built > into the kernel when a kernel is built by a developer. > > The .secondary_trusted_keys keyring introduced by commit d3bfe84129f6 > ("certs: Add a secondary system keyring that can be added to > dynamically") consists of the trustable keys that an end-user can add > dynamically after booting the kernel. When this kernel enables the > .machine keyring and an end user chooses to trust Machine Owner Keys > (MOK) provided by shim, MOK keys will be added to the .machine > keyring and the .machine keyring is be linked to the > secondary_trusted_keys so keys contained in the .machine keyring will > automatically be searched when searching secondary_trusted_keys. > > The .platform keyring introduced by commit 9dc92c45177a ("integrity: > Define a trusted platform keyring") consist of UEFI db and > MOK keys. If an end user chooses to Machine Owner 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. _______________________________________________ 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: Wed, 25 May 2022 09:30:40 -0400 Subject: [PATCH v8 0/4] use more system keyrings to verify arm64 and s390 kexec kernel image signature In-Reply-To: <20220525095957.vvref4yeaidd5iww@Rk> References: <20220512070123.29486-1-coxu@redhat.com> <20220525095957.vvref4yeaidd5iww@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 Wed, 2022-05-25 at 17:59 +0800, Coiby Xu wrote: > Hi Mimi, > > On Fri, May 20, 2022 at 01:04:47PM -0400, Mimi Zohar wrote: > >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 > > Thanks for the suggestion! I will start with an overall problem > description in next version. For me, the bigger problem is arm kexec > can't make use of .secondary_trusted_keys or .platform to verify kernel > image signature. The by-product of the solution is it also helps > address the problem of inconsistent usage of keyrings by kexec between > different arches. > > >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. > > It seems I lack some background knowledge that makes me fail to > appreciate what change the new .machine keyring brings to kexec. As far > as I can understand, the new .machine keyring doesn't seem to change > much about kexec kernel image signature verification. kexec should be > able to use MOK keys to verify signature regardless of the keys being > loaded into .platform keyring or into the new .machine keyring. Because > the MOK keys have already be used to verify the 1st booting kernel's > image signature. To me, the significance of the new .machine keyring is > the end-users-enrolled keys can be also used to verify kernel modules > (the end users can also add his key to the .secondary_trusted_keys > keyring but the key needs to vouched by any existing key from the > .builtin_trusted_keys or .secondary_trusted_keys which is nearly > impossible). "the significance of the new .machine keyring is the end-users-enrolled keys can be also used to verify kernel modules" correct. So any key stored in MOK and loaded onto the .machine keyring, could also then be used to verify the kexec'ed kernel image signature as well. > > > > >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. > > I don't find any code that links the .platform keyring to the > .secondary_trusted_keys keyring and one [1] of your replies to "[PATCH > 4/4] module, KEYS: Make use of platform keyring for signature > verification" is as follows, > "Permission for loading the pre-OS keys onto the 'platform' keyring and > using them is limited to verifying the kexec kernel image, nothing > else." Right, that should have been, "Both the .builtin_trusted_keys and .machine keyrings are linked ..." > > [1] https://lore.kernel.org/linux-arm-kernel/3e39412657a4b0839bcf38544d591959e89877b8.camel at linux.ibm.com/ > > >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. Linking the .machine keyring to the .secondary keyring impacts the root(s) of trust. > > Thanks for the suggestion! I'll add the following text in v9, do it > looks good to you? > > 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. On a physical system in a secure boot environment, this trust is rooted in HW. .machine: < explanation > .secondary_trusted_keys: For example, 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 < explanation > thanks, Mimi > The > .platform keyring could have both UEFI db keys and MOK keys or only UEFI > db keys. And the .machine keyring only have MOK keys. The root trust of > UEFI db keys is UEFI Platform Key which is shipped by an UEFI firmware > vendor. The root trust of MOK keys is a Linux distribution vendor (shim > has built-in MOK key) and the end user could also be another root of > trust if he/she enrolls his own key. > > The %.builtin_trusted_keys keyring consists of the trustable keys built > into the kernel when a kernel is built by a developer. > > The .secondary_trusted_keys keyring introduced by commit d3bfe84129f6 > ("certs: Add a secondary system keyring that can be added to > dynamically") consists of the trustable keys that an end-user can add > dynamically after booting the kernel. When this kernel enables the > .machine keyring and an end user chooses to trust Machine Owner Keys > (MOK) provided by shim, MOK keys will be added to the .machine > keyring and the .machine keyring is be linked to the > secondary_trusted_keys so keys contained in the .machine keyring will > automatically be searched when searching secondary_trusted_keys. > > The .platform keyring introduced by commit 9dc92c45177a ("integrity: > Define a trusted platform keyring") consist of UEFI db and > MOK keys. If an end user chooses to Machine Owner 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.