Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp3317777ioa; Tue, 26 Apr 2022 00:52:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxxumSyu8BzY5n4Ph0bQQxzz1Hb9xXXyut1POw5zFQ6Xzgc8HReGXYqg7QWzJ4kny0NgIeC X-Received: by 2002:a17:907:629c:b0:6e1:6ad:5dd8 with SMTP id nd28-20020a170907629c00b006e106ad5dd8mr19532848ejc.641.1650959557416; Tue, 26 Apr 2022 00:52:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650959557; cv=none; d=google.com; s=arc-20160816; b=WU5bon7Mgf7DgqQcqPnwFsgxHhGv9kj5s6yp8Ji2OnYsJV58YdG8XXWoxf2kqf6Sa0 Y1cszjJpKoG8aZgM4P+SdBNXXaDYSyCnGqwBjrlknlEV4pfytgEPyTjydhNHouo5oIno vGwj5Y1b/49INHB95MBHQ+36AmHArjj9fc/QGJW4geWPvHczIcjSujjEDq3YFoNf5MwX NysCnS+XqzzUJNZOE/TEtrN1Mwr1EZHyHdDuKXKFtWiLWu1qrsm4antFhOLuE1fkqtYx fgq6jBeQ5BZ1iDFvvv33P4iLLoc9OOAYuEOz/yfEYYnNaMoipZdXwWxkLxoW8FL5xM5G DSlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:user-agent:mime-version:date :message-id; bh=bA6F01zGCEtQIOgJrpZ+KjS7h8BH7jmyAKmYFljy1vM=; b=CpuQ76G12xw9RIoGYBHM3tOWdEKIWS5UkFuhc3MzzeHZvft1YwO7hOS4ucxg1O/BHE E2I7SdKNqINK0MtQGhovvar9yE6fjxhcFm+dhaDHXLNu+vnu1YU7Ea29zbfOO450Ih2F Hmb9MLZFP54ppUdzhQNtLAVgun8inSfojuCRNs/jsk6r44oj6dqzavj/ONZwsc6lo9QJ RGDm3Lpse4SnoX+/x3YsvQR1yYhgreb4BgrjM8zkZMTFKEXoRDrIxpshxS5chlO9fv6X 5/X1y9M3+RGhINY2vA/eO/4vq+1WvqEpSrHIfLb5yG9nNeXit7VQUflaxDAqg7mWVuwi qsBg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h2-20020a056402280200b0041d8586ad52si17059199ede.218.2022.04.26.00.52.14; Tue, 26 Apr 2022 00:52:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243971AbiDZENY (ORCPT + 99 others); Tue, 26 Apr 2022 00:13:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243948AbiDZENW (ORCPT ); Tue, 26 Apr 2022 00:13:22 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F18761080; Mon, 25 Apr 2022 21:10:15 -0700 (PDT) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4KnT1P2SRFzhYqg; Tue, 26 Apr 2022 12:10:01 +0800 (CST) Received: from [10.67.110.173] (10.67.110.173) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 26 Apr 2022 12:10:13 +0800 Message-ID: <853635d6-9e74-c3dc-f6dc-d4166616c8e5@huawei.com> Date: Tue, 26 Apr 2022 12:10:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: How to list keys used for kexec Content-Language: en-US To: =?UTF-8?Q?Michal_Such=c3=a1nek?= , "keyrings@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-security-module@vger.kernel.org" References: <20220414175930.GM163591@kunlun.suse.cz> From: "Guozihua (Scott)" In-Reply-To: <20220414175930.GM163591@kunlun.suse.cz> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.110.173] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500024.china.huawei.com (7.185.36.203) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/4/15 1:59, Michal Suchánek wrote: > Hello, > > apparently modules are verified by keys from 'secondary' keyring on all > platforms. > > If you happen to know that it's this particular keyring, and know how > to list keyrings recursively you can find the keys that are used for > verifying modules. > > However, for kexec we have > > - primary keyring on aarch64 > - platform keyring on s390 > - secondary AND platform keyring on x86 > > How is a user supposed to know which keys are used for kexec image > verification? > > There is an implicit keyring that is ad-hoc constructed by the code that > does the kexec verification but there is no key list observable from > userspace that corresponds to this ad-hoc keyring only known to the kexec > code. > > Can the kernel make the information which keys are used for what purpose > available to the user? > > Thanks > > Michal > > . Hi Michal I'll try my best to understand and answer your question. First of all, the "key" you mentioned here is actually certificate. And there are no way for the kernel to know "which certificate is used for what purpose" but to get a hint from the certificate's extension, if they exist. However, the extension only points out what this certificate should be used for, but not exactly what it is actually used for. Secondly, the verification process requires the module (kernel image in this question) to contain information on which certificate should be used to verify itself. The signature provided by the module is in PKCS#7 format which contains a list of certificates for the verifier to construct a "chain of trust". Each certificates contains information pointing to the certificate of it's issuer, and eventually to one of the certificate stored in one of the keyrings you mentioned. All in all, certificates in these keyrings you mentioned can be used for various purpose, and it's the responsibility for the modules being verified to provide information stating which certificate should be used for verification. Thus, the best way to find out which key is used for kexec is to look at key used to sign the kernel image. -- Best GUO Zihua