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 BE26CC433EF for ; Sun, 20 Mar 2022 21:03:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343649AbiCTVEx (ORCPT ); Sun, 20 Mar 2022 17:04:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233463AbiCTVEw (ORCPT ); Sun, 20 Mar 2022 17:04:52 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4F6E59384; Sun, 20 Mar 2022 14:03:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7545EB80E0E; Sun, 20 Mar 2022 21:03:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52CCEC340E9; Sun, 20 Mar 2022 21:03:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647810206; bh=b6J0AaU317Tzh6IzUdIfF4nn+9FPVkNTnPYZOaj147k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MnX2Q1+s3Gg0F3AbRzSzJAGL0XDG4ustbeT9ttK/OtkyWuRBdUkYl0z5aZ1AfjfxA 672qLJdiXc73sa9wq2izyW+5Ri+srhYAwZ3ZghL9A0mxCg4rFW2yzXRyfDTJhkTNza jNCjb8gMUD5O2HwnQfvCmKShTw2NSBWaEepfS2Q/YGxwzRx1ssO860QpzkMFsKVV48 XPePNz0klm23tIWmT967FRlYmsT6pZABtNRH/sSxljdYiJeFQ4cd7IK6dNn3Ytv9qi 2Gpkl9n1hRNuBcLvzg9yiGEtpNdolZpzsE2UoV94DVSc5axJxsTr909nf6G4byJO1/ T0mnTehyJhfTw== Date: Sun, 20 Mar 2022 23:04:26 +0200 From: Jarkko Sakkinen To: Paul Moore Cc: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , David Howells , David Woodhouse , "David S . Miller" , Eric Snowberg , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 1/2] certs: Remove panic() calls from blacklist_init() Message-ID: References: <20220311174741.250424-1-mic@digikod.net> <20220311174741.250424-2-mic@digikod.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Mar 11, 2022 at 05:00:32PM -0500, Paul Moore wrote: > On Fri, Mar 11, 2022 at 12:47 PM Mickaël Salaün wrote: > > From: Mickaël Salaün > > > > Replace panic() calls from device_initcall(blacklist_init) with proper > > error handling using -ENODEV. > > > > Suggested-by: Jarkko Sakkinen [1] > > Link: https://lore.kernel.org/r/Yik0C2t7G272YZ73@iki.fi [1] > > Signed-off-by: Mickaël Salaün > > Link: https://lore.kernel.org/r/20220311174741.250424-2-mic@digikod.net > > --- > > certs/blacklist.c | 27 +++++++++++++++++++++------ > > 1 file changed, 21 insertions(+), 6 deletions(-) > > I'm not sure we can safely rely on a non-zero error code saving us in > the care of failure, can we? > > The blacklist_init() function is registered as an initcall via > device_initcall() which I believe is either executed via > do_init_module() in the case of a dynamic module load, or via > do_initcalls() if built into the kernel. In either case the result is > that the module/functionality doesn't load and the kernel continues on > executing. While this could be acceptable for some non-critical > modules, if this particular module fails to load it defeats the > certificate/key based deny list for signed modules, yes? > > I completely understand the strong desire to purge the kernel of > panic()s, BUG()s, and the like, but if a critical piece of security > functionality that users expect to be present fails to initialize, > panic()ing is likely the right thing to do. OK, I get this. What this function should have is this information documented in the header. Otherwise, this is just confusing. BR, Jarkko