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 6D2E4C433F5 for ; Fri, 27 May 2022 13:46:45 +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=GlfYCXp7m7GMgUloxHeLaUMSyqRqK8ooN9dQwV2T7es=; b=pkELxP7297xhKCn9wAKE6ySKKK luV+k0zJKWcrAhyWFx9DeciBACcWEifnSL620u+T96UngWm3w/S8CDHoSrjtK2zUAgqtchQkDKZBw iQmF2CXKQzTE33QkcO166/bVgiSF1VhZ4cZpvljYrb3nbMMb9ykiZhQRzhj9f6uKNgP68V6Ht7STR nIcjBOv2BPs/fgeSL/NCTTO5CXz6gRti+HIiS1K/5nPhf+B10JGqFkQsrYztzr1MgFJ3srSLz6/Fn mO3RjE8iuZQVWuAHOEmmC6w8d6HlUJdWngg2VC7LSKfk00fcTqanx5Zf5N3JjbR/IychsHVmegLbz BLFXpVrQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nuaHT-0009mu-LO; Fri, 27 May 2022 13:45:31 +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 1nuaHI-0009jU-Dy for linux-arm-kernel@lists.infradead.org; Fri, 27 May 2022 13:45:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653659113; 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=AfGJJGwI299bqX9MrLv02V4LpRzMN3auNArSHHSZdyc=; b=Ua2iq2lI1cX1tI3R7ONMPnRFBaTkbLbSzC0OEA5CbirTaWPOrFteztZuPprW6bzD+B8BDe PSX6TyBeGwRGv2D4hbfOqKv2C6LtY/Z61PoAw5OHJVA9uZJWTtDXqfjBqPoUkCzvlYfFqq YNavZtW9RzlduyUCJBL979mfNn0f/uY= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-629-fRecvrsEPl-Gx9srI7Yn8w-1; Fri, 27 May 2022 09:45:12 -0400 X-MC-Unique: fRecvrsEPl-Gx9srI7Yn8w-1 Received: by mail-pf1-f198.google.com with SMTP id m12-20020aa7900c000000b005183e9b0fd5so2507992pfo.23 for ; Fri, 27 May 2022 06:45:12 -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=AfGJJGwI299bqX9MrLv02V4LpRzMN3auNArSHHSZdyc=; b=TdKHmUJGAmU8LVT3k9TPvOXKbWkQkdzlLoB0NQ4asB+umLTql3+iPurtUGjtGBpj9B ReiaI1qjBJ+NRulRNLeBlitNJEw0Ya5eelYJocw6U7SXJLK4A7PrqzfkOYCs+gPhuKV/ RIOaZheDwfGieNEJxRGk/uNcFTxTZ3wj8G7jeBRyB80kmoJdLJe6knQvu4b5l4XxZbBf ozMSOx6h+HP8w0iZ9Ox49qXAEp4RvpqDQhzP31yPh/e+6EuCW8VHvsNhC1QKChPBpNmO TmgO5wyO/L51CkS4vAbHFiHorH66Npwcu6pKKY9HMjzPPc0i0t4yXg7al7jvjG8FuFAd OkXg== X-Gm-Message-State: AOAM533o/5Bf9gyAg3iKt3vIU9ND8OZXur7hyNGd68FAGpbbyY2kOokA lTg6wg3bRCVmqIzE+q7fg8kGv41qHtJQWLvS1B3ZpSSAiCVwqDe9Lh4+LY9I5MBNY2ZgbFyVsBI NDqcRWlRpeyQGHOkkZA8YYSASGrHC+c9zLj4= X-Received: by 2002:a17:903:292:b0:15f:171:e794 with SMTP id j18-20020a170903029200b0015f0171e794mr43195279plr.107.1653659111359; Fri, 27 May 2022 06:45:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwipfqimCd2wylfst/y90dVTnB8BMWMf914p/3ox5STawrAjsm0d4VjFlcp4lrNMTwxBTd8WA== X-Received: by 2002:a17:903:292:b0:15f:171:e794 with SMTP id j18-20020a170903029200b0015f0171e794mr43195248plr.107.1653659111022; Fri, 27 May 2022 06:45:11 -0700 (PDT) Received: from localhost ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id p1-20020a170902f08100b0015e8d4eb22esm3579670pla.120.2022.05.27.06.45.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 May 2022 06:45:10 -0700 (PDT) Date: Fri, 27 May 2022 21:43:15 +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: <20220527134315.afnuszqbfqkpnxpv@Rk> References: <20220512070123.29486-1-coxu@redhat.com> <20220525095957.vvref4yeaidd5iww@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-20220527_064520_995075_14B2812C X-CRM114-Status: GOOD ( 35.80 ) 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 Mini, It seems I need to only change cover letter and commit message i.e. there is no concern about the code. So it's better to provide a new cover letter here to collect new feedback from you thus we can avoid unnecessary rounds of patch set. 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. 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. 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, .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. .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 .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 be hardware or the end-users. On Wed, May 25, 2022 at 09:30:40AM -0400, Mimi Zohar wrote: >On Wed, 2022-05-25 at 17:59 +0800, Coiby Xu wrote: >> Hi Mimi, >> [...] >> 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. Thanks for explanation! > [...] >> > >> >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 ..." Thanks for the confirmation! I should have realized it's a typo. > >> >> [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 clarification! > >> >> 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. 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. > 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 Thanks for providing the examples! -- Best regards, Coiby _______________________________________________ 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: Coiby Xu Date: Fri, 27 May 2022 21:43:15 +0800 Subject: [PATCH v8 0/4] use more system keyrings to verify arm64 and s390 kexec kernel image signature In-Reply-To: References: <20220512070123.29486-1-coxu@redhat.com> <20220525095957.vvref4yeaidd5iww@Rk> Message-ID: <20220527134315.afnuszqbfqkpnxpv@Rk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kexec@lists.infradead.org Hi Mini, It seems I need to only change cover letter and commit message i.e. there is no concern about the code. So it's better to provide a new cover letter here to collect new feedback from you thus we can avoid unnecessary rounds of patch set. 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. 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. 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, .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. .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 .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 be hardware or the end-users. On Wed, May 25, 2022 at 09:30:40AM -0400, Mimi Zohar wrote: >On Wed, 2022-05-25 at 17:59 +0800, Coiby Xu wrote: >> Hi Mimi, >> [...] >> 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. Thanks for explanation! > [...] >> > >> >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 ..." Thanks for the confirmation! I should have realized it's a typo. > >> >> [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 clarification! > >> >> 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. 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. > 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 Thanks for providing the examples! -- Best regards, Coiby