From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752531AbeCOOab (ORCPT ); Thu, 15 Mar 2018 10:30:31 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:36006 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752476AbeCOOa3 (ORCPT ); Thu, 15 Mar 2018 10:30:29 -0400 Message-ID: <1521124226.5348.15.camel@HansenPartnership.com> Subject: Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module From: James Bottomley To: joeyli Cc: "Lee, Chun-Yi" , David Howells , linux-fs@vger.kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Josh Boyer Date: Thu, 15 Mar 2018 07:30:26 -0700 In-Reply-To: <20180315061650.GA10628@linux-l9pv.suse> References: <20180313103803.13388-1-jlee@suse.com> <20180313103803.13388-5-jlee@suse.com> <1520961515.5360.19.camel@HansenPartnership.com> <20180314060803.GD19718@linux-l9pv.suse> <1521037165.4508.13.camel@HansenPartnership.com> <20180315061650.GA10628@linux-l9pv.suse> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2018-03-15 at 14:16 +0800, joeyli wrote: > On Wed, Mar 14, 2018 at 07:19:25AM -0700, James Bottomley wrote: > > > > On Wed, 2018-03-14 at 14:08 +0800, joeyli wrote: > > > > > > On Tue, Mar 13, 2018 at 10:18:35AM -0700, James Bottomley wrote: > > > > > > > > > > > > On Tue, 2018-03-13 at 18:38 +0800, Lee, Chun-Yi wrote: > > > > > > > > > > > > > > > This patch adds the logic for checking the kernel module's > > > > > hash base on blacklist. The hash must be generated by sha256 > > > > > and enrolled to dbx/mokx. > > > > > > > > > > For example: > > > > > sha256sum sample.ko > > > > > mokutil --mokx --import-hash $HASH_RESULT > > > > > > > > > > Whether the signature on ko file is stripped or not, the hash > > > > > can be compared by kernel. > > > > > > > > What's the use case for this?  We're already in trouble from > > > > the ODMs for the size of dbx and its consumption of the > > > > extremely limited variable space, so do we really have a use > > > > case for adding module blacklist hashes to the UEFI variables > > > > given the space constraints (as in one we can't do any other > > > > way)? > > > > > > > > > > The dbx is a authenticated variable that it can only be updated > > > by manufacturer. The mokx gives a flexible way for distro to > > > revoke a key or a signed module. Then we don't need to touch shim > > > or bother manufacturer to deliver new db. Currently it doesn't > > > have real use case yet.  > > > > > > I knew that the NVRAM has limited space. But distro needs a > > > backup solution for emergency. > > > > I wasn't asking why the variable, I was asking why the mechanism. > > > > OK, let me try to ask the question in a different way: > > > > Why would the distribution need to blacklist a module in this way? > >  For > > This way is a new option for user to blacklist a module but not the > only way. So this is for the *user* not the distribution? > MOK has this ability because shim implements the mokx by signature > database format (EFI_SIGNATURE_DATA in UEFI spec). This format > supports both hash signature and x.509 certificate. > > > > > the distro to execute the script to add this blacklist, means the > > system is getting automated or manual updates ... can't those > > updates just remove the module? > > > Yes, we can just remove or update the module in kernel rpm or kmp. > But user may re-install distro with old kernel or install a old kmp. > If the blacklist hash was stored in variable, then kernel can prevent > to load the module. > > On the other hand, for enrolling mokx, user must reboots system and > deals with shim-mokmanager UI. It's more secure because user should > really know what he does. And user can choice not to enroll the hash > if they still want to use the module. OK, so now the use case is the user needs to roll back but doesn't want a module to load ... I've got to say that in that case I'd just remove it before reload. > > The point is that module sha sums are pretty ephemeral in our model > > (they change with every kernel), so it seems to be a mismatch to > > place them in a permanent blacklist, particularly when we have very > > limited space for that list. > > > Normally we run a serious process for signing a kernel module before > shipping it to customer. The SUSE's "Partner Linux Driver Program” > (PLDP) is an example. So the module sha sums are not too ephemeral. Ephemeral isn't about the signing process it means that the sum is short lived because every time you create a module for a specific kernel its sum changes (because of the interface versioning) so your blacklist only applies to one module and specific kernel combination.  Once you compile it for a different kernel you need a different blacklist sum for it. James