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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2337C4332F for ; Tue, 15 Feb 2022 20:47:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244152AbiBOUro (ORCPT ); Tue, 15 Feb 2022 15:47:44 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:35886 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237521AbiBOUro (ORCPT ); Tue, 15 Feb 2022 15:47:44 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4FD685FBF; Tue, 15 Feb 2022 12:47:33 -0800 (PST) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id C8A071F37B; Tue, 15 Feb 2022 20:47:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1644958051; h=from:from:reply-to: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=FlfsyHCAs0rdIX//YatnIpiwimkoa18Lt0kLGHb4O7E=; b=OARPnhmPW7qBVTlDY6oU/h/RXco0jkDnGZJwh7Qzb65K1gtp0B2Y2N4GnqEQYZj8Pp0sbN AdWt2MzVAqrrwO2oUaXSeVgeRYwF7OkNORYRlp22XWtm7O3mKr6KnB4guXqUfnnJUu94GW vPY36B6Jf3wxAgqmLYS26q1rp+O/vzs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1644958051; h=from:from:reply-to: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=FlfsyHCAs0rdIX//YatnIpiwimkoa18Lt0kLGHb4O7E=; b=J6eCNMY6o4jcfwtx/YyCr2tGzh12PjjFMaNcT6a8Lmgs3C8jzDsc69GNV/ct8k1n8uhUHY wg2yBhsE/yKZ73Dw== Received: from kunlun.suse.cz (unknown [10.100.128.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 83940A3B83; Tue, 15 Feb 2022 20:47:31 +0000 (UTC) Date: Tue, 15 Feb 2022 21:47:30 +0100 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Mimi Zohar Cc: Catalin Marinas , Will Deacon , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Philipp Rudo , Baoquan He , Alexander Egorenkov , AKASHI Takahiro , James Morse , Dave Young , Kairui Song , Martin Schwidefsky , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-modules@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, stable@kernel.org, Eric Snowberg Subject: Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification Message-ID: <20220215204730.GQ3113@kunlun.suse.cz> References: <840433bc93a58d6dfc4d96c34c0c3b158a0e669d.1644953683.git.msuchanek@suse.de> <3e39412657a4b0839bcf38544d591959e89877b8.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e39412657a4b0839bcf38544d591959e89877b8.camel@linux.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: keyrings@vger.kernel.org Hello, On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > [Cc'ing Eric Snowberg] > > Hi Michal, > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > > adds support for use of platform keyring in kexec verification but > > support for modules is missing. > > > > Add support for verification of modules with keys from platform keyring > > as well. > > Permission for loading the pre-OS keys onto the "platform" keyring and > using them is limited to verifying the kexec kernel image, nothing > else. Why is the platform keyring limited to kexec, and nothing else? It should either be used for everything or for nothing. You have the option to compile it in and then it should be used, and the option to not compile it in and then it cannot be used. There are two basic use cases: (1) there is a vendor key which is very hard to use so you sign something small and simple like shim with the vendor key, and sign your kernel and modules with your own key that's typically enrolled with shim MOK, and built into the kernel. (2) you import your key into the firmware, and possibly disable the vendor key. You can load the kernel directly without shim, and then your signing key is typically in the platform keyring and built into the kernel. In neither case do I see any reason to use some keyrings for kexec and other keyrings for modules. Thanks Michal 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 B2B21C433F5 for ; Tue, 15 Feb 2022 20:48: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-Transfer-Encoding:Content-Type: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=0dBNsCGbpPsBFz1Wf6abFY5mt1/XzvE9PIDHAXSiGCU=; b=vui3IKgyIMuhIC iJVq2PfKZnwWFC38eU5jKi6ChtTbOR984bd7U1BTX5Rd1BBYAVs//sbd/4X/rktM1TCaXJVmGvsYf mRFBVI8SZ6WLsapsoiVCDFb450TRHuTrAwZvabDULsY9HCw2bk6VIMilnf45E/RX8HnHiR8BR4/hy K91VfipdovcDqasXtwT2Yua7G/O56v8Ul7uxH5zwLQjWSIF6VSVmUUYQK7SQQc2sDBuJwhIvgzZD+ ak7Eu9giDnYW7qvwa+XnaWULxMjoal5mjIpUt4ysZjElTCMm9mKJYfZHhDlF5XKLhdZ+Ofd1xNS0m wI/HdxNe8uAMJAwZeeqQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nK4jZ-004aAB-Kg; Tue, 15 Feb 2022 20:47:37 +0000 Received: from smtp-out2.suse.de ([195.135.220.29]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nK4jV-004a91-QR for linux-arm-kernel@lists.infradead.org; Tue, 15 Feb 2022 20:47:35 +0000 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id C8A071F37B; Tue, 15 Feb 2022 20:47:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1644958051; h=from:from:reply-to: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=FlfsyHCAs0rdIX//YatnIpiwimkoa18Lt0kLGHb4O7E=; b=OARPnhmPW7qBVTlDY6oU/h/RXco0jkDnGZJwh7Qzb65K1gtp0B2Y2N4GnqEQYZj8Pp0sbN AdWt2MzVAqrrwO2oUaXSeVgeRYwF7OkNORYRlp22XWtm7O3mKr6KnB4guXqUfnnJUu94GW vPY36B6Jf3wxAgqmLYS26q1rp+O/vzs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1644958051; h=from:from:reply-to: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=FlfsyHCAs0rdIX//YatnIpiwimkoa18Lt0kLGHb4O7E=; b=J6eCNMY6o4jcfwtx/YyCr2tGzh12PjjFMaNcT6a8Lmgs3C8jzDsc69GNV/ct8k1n8uhUHY wg2yBhsE/yKZ73Dw== Received: from kunlun.suse.cz (unknown [10.100.128.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 83940A3B83; Tue, 15 Feb 2022 20:47:31 +0000 (UTC) Date: Tue, 15 Feb 2022 21:47:30 +0100 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Mimi Zohar Cc: Catalin Marinas , Will Deacon , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Philipp Rudo , Baoquan He , Alexander Egorenkov , AKASHI Takahiro , James Morse , Dave Young , Kairui Song , Martin Schwidefsky , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-modules@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, stable@kernel.org, Eric Snowberg Subject: Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification Message-ID: <20220215204730.GQ3113@kunlun.suse.cz> References: <840433bc93a58d6dfc4d96c34c0c3b158a0e669d.1644953683.git.msuchanek@suse.de> <3e39412657a4b0839bcf38544d591959e89877b8.camel@linux.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3e39412657a4b0839bcf38544d591959e89877b8.camel@linux.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220215_124734_029931_436375C8 X-CRM114-Status: GOOD ( 20.45 ) 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 Hello, On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote: > [Cc'ing Eric Snowberg] > > Hi Michal, > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote: > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") > > adds support for use of platform keyring in kexec verification but > > support for modules is missing. > > > > Add support for verification of modules with keys from platform keyring > > as well. > > Permission for loading the pre-OS keys onto the "platform" keyring and > using them is limited to verifying the kexec kernel image, nothing > else. Why is the platform keyring limited to kexec, and nothing else? It should either be used for everything or for nothing. You have the option to compile it in and then it should be used, and the option to not compile it in and then it cannot be used. There are two basic use cases: (1) there is a vendor key which is very hard to use so you sign something small and simple like shim with the vendor key, and sign your kernel and modules with your own key that's typically enrolled with shim MOK, and built into the kernel. (2) you import your key into the firmware, and possibly disable the vendor key. You can load the kernel directly without shim, and then your signing key is typically in the platform keyring and built into the kernel. In neither case do I see any reason to use some keyrings for kexec and other keyrings for modules. Thanks Michal _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel