Received: by 10.213.65.68 with SMTP id h4csp223398imn; Fri, 16 Mar 2018 00:35:43 -0700 (PDT) X-Google-Smtp-Source: AG47ELuCcPXa/A0H/PKLQ/FUeDj01DXpH0ws/qM3j9sQdtYflBfySe7Z49oyFVh75cgHY6D+bOdh X-Received: by 2002:a17:902:143:: with SMTP id 61-v6mr991543plb.345.1521185743170; Fri, 16 Mar 2018 00:35:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521185743; cv=none; d=google.com; s=arc-20160816; b=A7mfiz5+1NHws8jCuZN9PyeAcxXzc5eQR6Ekvb0258ds2Anxe9NjqJmnzgK1BZdBQ0 u1fnbkpCFZ6y+HKdlkfg6OenQLbG6S3CYFgYgczlyqDD/em0PxjG+VZBf5Qo7EyMz+jj SsIR20W4Q1owL/YnVQg1rmuv1JNoU6hj8VJwANOZZMs/xus/i9Gl9EH2U6BaUPbH1Pon vpwoTVq7EaENbSI+wbb6N1kCi/kOQ3Za51EOSYMTrTvK7aznFtiT2tvvEjVCyY2E1uFx gyg1iON6q59L6JkFp8H39PRDB6pBhaCPwm/giZYeGrlbIcGgHrKZOK/BZ/fejvy4skay nktA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=yhrBYjQoX9Aq/487B/P1dJlXCjM+QWv/9lr8FeeV5JY=; b=Eeymt0FtHuno72ff9YrPyxcH+GQYdyNNkkDNUDfoza2x314m+bQdYXvZdlVZ6Ykao0 Hv5sAC++3QljnjaPHM8p5XShGbNOp1KvpG+iVWd3e3xM4+CCfnz8y1ax7MFYZ0maNbI7 xf+knNiICojTH2ghj/DRSDm3QTd2+a+RJQa0TW8MvOVsrI24pEYTXJ5LZeDbCCQq1WSs 58gZeECPFEx+6/cpBcXV39lYmF+1mrqcD0J6unYFAcoGdyZdaDUEpGXhZBDYStn92BtV wSvITwoYF7oa1tvebxPbjjcH22NfyFECYdXYjQyOkkNEyyhQtV3BZpr8q2OQcJbGi0Mj Q6NA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c7si5046271pfi.323.2018.03.16.00.35.29; Fri, 16 Mar 2018 00:35:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753192AbeCPHdC (ORCPT + 99 others); Fri, 16 Mar 2018 03:33:02 -0400 Received: from smtp.nue.novell.com ([195.135.221.5]:54096 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753131AbeCPHdB (ORCPT ); Fri, 16 Mar 2018 03:33:01 -0400 Received: from linux-l9pv.suse (unknown.telstraglobal.net [134.159.103.118]) by smtp.nue.novell.com with ESMTP (TLS encrypted); Fri, 16 Mar 2018 08:32:56 +0100 Date: Fri, 16 Mar 2018 15:32:49 +0800 From: joeyli To: James Bottomley Cc: "Lee, Chun-Yi" , David Howells , linux-fs@vger.kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Josh Boyer Subject: Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module Message-ID: <20180316073249.GF15088@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> <1521124226.5348.15.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1521124226.5348.15.camel@HansenPartnership.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 15, 2018 at 07:30:26AM -0700, James Bottomley wrote: > 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. > I agree with you that the sum is ephemeral. I will remove this patch from the mokx series. The certificate in mokx will be loaded to blacklist keyring. Which means that we still can use mokx to revoke public key. But kernel will not check the blacklisted hash before loading kernel module. Thanks a lot! Joey Lee