Received: by 10.213.65.68 with SMTP id h4csp785557imn; Tue, 13 Mar 2018 23:09:42 -0700 (PDT) X-Google-Smtp-Source: AG47ELtG1Ku01k1YHF+bDh5PAcYY6WeyAqCgZ9PG5HBNbgBGrTZ+M/0bZjDFf9luym6m9NG0Yde3 X-Received: by 10.99.105.7 with SMTP id e7mr2670417pgc.193.1521007782645; Tue, 13 Mar 2018 23:09:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521007782; cv=none; d=google.com; s=arc-20160816; b=q8b+Qfbaif5/RSm1ywaMe6lQSjGBjG7S8bUlmVrmLO9PkveJRqgyLKhRhjDu8cVuWZ zSc/bh1K3cO2O1QQJdGSH137IB5wu4KWxmz8n6PKF0Zx6UIEHE7sj48owHFrE3Lat9Qe OshdfeHrnEOEAAKqEUDfJR8oy+nFlc+Deg1LM3ZGB285CEjO2EtEKGjLxA0lDayCG5C+ tfqdeQoXteTH2NSA5dXiFJcoVna6ZOe5CKgCQ+zVWGiAUV3Qqk+EXus5OvJCSAzDk9Wr R5CMqO84i8icxm2X8OUY9sjzt21BHfr13AngrAbeoHxW6vC7d3dPrLLbFumChjzCOkZ2 Lfug== 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=2F1kOEv8y2LO11wKAjPlxVLvGdHoUZCrPSag/r6ff5o=; b=mEWy62n8mfdqkoAV6tbhO8Jmi9I/M6e6cG8LqGCjtcddQYWJYhHML/jQ0JE60Avnbi 8D6Scox/dUXf1aFQ9HzxI+iACvFE435pMwImmYXlBHDoYBwgeT0Ft6YSjm/8HZA4ERFA 2dfLzyTFscM2LPA/bGek6zifsLMsz+BzfL91svk8WeFA18cGZ4xrPByjqxV49V+9CN0L U+76KGMBPqw6CUN3vW1yJKkNbHTDZuKQxSPQuO2DB9tIk92twkYjzq88ujluFLL+pikB 9MJYYqESg6mJh5Edy8J76u58CiUlkshHqGOo82HN6U2oz3oU2EkcOLtfr/8YcN07d8p1 bZpg== 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 p11-v6si1409015plo.619.2018.03.13.23.09.28; Tue, 13 Mar 2018 23:09:42 -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 S1753434AbeCNGIZ (ORCPT + 99 others); Wed, 14 Mar 2018 02:08:25 -0400 Received: from smtp.nue.novell.com ([195.135.221.5]:46518 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751426AbeCNGIP (ORCPT ); Wed, 14 Mar 2018 02:08:15 -0400 Received: from linux-l9pv.suse (unknown.telstraglobal.net [134.159.103.118]) by smtp.nue.novell.com with ESMTP (TLS encrypted); Wed, 14 Mar 2018 07:08:10 +0100 Date: Wed, 14 Mar 2018 14:08:03 +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: <20180314060803.GD19718@linux-l9pv.suse> References: <20180313103803.13388-1-jlee@suse.com> <20180313103803.13388-5-jlee@suse.com> <1520961515.5360.19.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1520961515.5360.19.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 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. Thanks a lot! Joey Lee