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 54876C43334 for ; Thu, 16 Jun 2022 01:21:52 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vPVusDBMsVuaUQDGXrEq6Q+K518L/PudGO4M2ezipp4=; b=bxPpbjjb6OcASTKwnNHcjzw9Sy x1coyzY3yNnDtWh3eBi6UEFBJ5qhCNwywQRoX7oVOLpBP0JGe7ClLk5iJenTu4Y7EO9v9c1Q/UOX1 QOpREmp4Lv05ItG/IyY6ryS5ZVonem99SZyqv9lcd8Dl8HbonW1bL/SNYngJJp81cHULm5iv5M9VI +j37Lzb6WTo8fCCr7KCOvDKiRoZt839FyzZtzfaa6OlxPB/ie9aeX3GOsnBRp3i9opTEMMLsD6ElE DZ0P1p5OLOAs2rWoO4YTHKYT99Xxb8gUQTn6N7vDd8GMEtP2yd3dNsjP7C5/rxJzx5A1QBEw/T+WQ NWKvYZRQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o1eBL-00HNO5-Dx; Thu, 16 Jun 2022 01:20:23 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o1eBI-00HNKt-Di for linux-arm-kernel@lists.infradead.org; Thu, 16 Jun 2022 01:20:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655342416; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cUR6nWOeJsMYO8qiB/3GvSDR9XKhnZ2gA6LlsAwErmg=; b=CEsjUeV8G4iB/eXtUksVky75RniU9zy3KLQiU+3RaJ/FBrmJQotOWmGjAECpGbvaCnrnYT vpgXMF05QXdiYoTuC0usdY0KUGIKsW2EacydOQ+KWFlX9HsIVaT2ziZJpP4afUyVx7HRq+ /gBe7YboDzJsmXSFK8SdMfHgoMO33sc= Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-389-6j5eDfoqPkePw-74AN9LSg-1; Wed, 15 Jun 2022 21:20:15 -0400 X-MC-Unique: 6j5eDfoqPkePw-74AN9LSg-1 Received: by mail-pl1-f200.google.com with SMTP id c10-20020a170903234a00b00168b5f7661bso59058plh.6 for ; Wed, 15 Jun 2022 18:20:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=cUR6nWOeJsMYO8qiB/3GvSDR9XKhnZ2gA6LlsAwErmg=; b=D+mtJMMkW14Ah922yQ1nm3Rz3TjhealdOuuVSqGXAoNkVnZxJwCdfbnUbV8n3xMAB2 ngFTzIBKbxB47XuiQWaO/ZVt3NtRyAvweI5W3hexlIoOGhZZ448z/tyejYkCU/Mf4Yk/ 1D+6Nq0EKyTXpJWh3RmyCJc495kZBc7GVz+asi+2PDe+5Z4OAVoG+Bl/BGXsJDRT9bdG tpkohPJnPl2F+yIALsGeRTmBeS9dji/mZH7uXsCbOIsqF1kaBamkON1D39V71rzS2AB1 u1bTLzHnFwQV/r/jjsPU5y8qhzxVS+9EKG0qs5EX6TF4eu0QwHw+0Ou4qvVwoGRb/Kc2 WUUw== X-Gm-Message-State: AJIora/695xVxlRUuKDHn/F136Q6Aimp9a3TKzp+Zna86PH2b6wsJvHS Yg93DUnTkFBCccioQhTcWWfvrmBEtWcrTDoFLZYrTFvKeiZFzXtG8TWfJTis0sl/3b4xHyHw90E DX61QKb3p5WjXLixSFe1f6Hgg7htLlczVZpw= X-Received: by 2002:a17:90b:4a90:b0:1e8:626c:e1b2 with SMTP id lp16-20020a17090b4a9000b001e8626ce1b2mr2294015pjb.141.1655342414204; Wed, 15 Jun 2022 18:20:14 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sqn3VKAg0dT9yU0B8MQXd7ZqDFnMewBiFUBEgCK9ufgmpXuBk8K/IcHn1AjJ01Rre8BgZIZA== X-Received: by 2002:a17:90b:4a90:b0:1e8:626c:e1b2 with SMTP id lp16-20020a17090b4a9000b001e8626ce1b2mr2293986pjb.141.1655342413815; Wed, 15 Jun 2022 18:20:13 -0700 (PDT) Received: from localhost ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id y14-20020a170902d64e00b0016397da033csm281330plh.62.2022.06.15.18.20.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jun 2022 18:20:13 -0700 (PDT) Date: Thu, 16 Jun 2022 09:15:06 +0800 From: Coiby Xu To: Mimi Zohar 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 Subject: Re: [PATCH v8 0/4] use more system keyrings to verify arm64 and s390 kexec kernel image signature Message-ID: <20220616011506.ymbz2xuhw3refasw@Rk> References: <20220512070123.29486-1-coxu@redhat.com> <20220525095957.vvref4yeaidd5iww@Rk> <20220527134315.afnuszqbfqkpnxpv@Rk> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=coxu@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220615_182020_590499_FBA86E5D X-CRM114-Status: GOOD ( 34.23 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Mimi, Thanks for carefully reviewing the covert letter and patches and suggesting various improvements! And sorry for the late reply as I need some time to learn more about secure boot, lockdown and IMA to better make sense of what you mean. On Fri, May 27, 2022 at 12:45:54PM -0400, Mimi Zohar wrote: > >> 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" Thanks for catching those typos and improving the wording! > >> .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. How about "the keys will be added to this keyring which is linked to the..."? > >> .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"? Thanks for catching these issues as well! > > > >> >> >> >> 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. Thanks for correcting me! I was a bit confused by secure boot and lockdown and also forgot enabling lockdown automatically when secure boot is enabled is a downstream feature. Btw, when testing the 4th s390 patch, I found s390 skip signature validation when secure boot is not enabled, is this a mistake? // arch/s390/kernel/machine_kexec_file.c #ifdef CONFIG_KEXEC_SIG int s390_verify_sig(const char *kernel, unsigned long kernel_len) { /* Skip signature verification when not secure IPLed. */ if (!ipl_secure_flag) return 0; > 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. Thanks for explaining IMA to me! There is still the question of what's the root of trust for .builtin_trusted_keys when there is no real signature verification. For example, when CONFIG_KEXEC_SIG is enabled, the default IMA policy is to not appraise kexec image. Since lockdown is not enabled by default, there is no real verification as kimage_validate_signature succeeds even when kexec_image_verify_sig fails. > >[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 > -- Best regards, Coiby _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel