Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751686AbdHGDXo (ORCPT ); Sun, 6 Aug 2017 23:23:44 -0400 Received: from mail-it0-f42.google.com ([209.85.214.42]:35680 "EHLO mail-it0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751366AbdHGDXn (ORCPT ); Sun, 6 Aug 2017 23:23:43 -0400 MIME-Version: 1.0 In-Reply-To: <8760e0xfbb.fsf@rustcorp.com.au> References: <20170804180751.14896-1-mjg59@google.com> <878tixxk2j.fsf@rustcorp.com.au> <8760e0xfbb.fsf@rustcorp.com.au> From: Matthew Garrett Date: Sun, 6 Aug 2017 20:23:42 -0700 Message-ID: Subject: Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled To: Rusty Russell Cc: linux-kernel@vger.kernel.org, jeyu@kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1469 Lines: 33 On Sun, Aug 6, 2017 at 7:49 PM, Rusty Russell wrote: > Matthew Garrett writes: >> Binary modules will still be tainted by the license checker. The issue >> is that if you want to enforce module signatures under *some* >> circumstances, you need to build with CONFIG_MODULE_SIG > > Not at all! You can validate them in userspace. And then you need an entire trusted userland, at which point you can assert that the modules are trustworthy without having to validate them so you don't need CONFIG_MODULE_SIG anyway. >> but that >> changes the behaviour of the kernel even when you're not enforcing >> module signatures. The same kernel may be used in environments where >> you can verify the kernel and environments where you can't, and in the >> latter you may not care that modules are unsigned. In that scenario, >> tainting doesn't buy you anything. > > With your patch, you don't get tainting in the environment where you can > verify. You don't anyway, do you? Loading has already failed before this point if sig_enforce is set. > You'd be better adding a sysctl or equiv. to turn off force loading, and > use that in your can-verify system. I'm not sure what you mean by "force loading" here - if sig_enforce is set, you can't force load an unsigned module. If sig_enforce isn't set, you'll taint regardless of whether or not you force. Wait. Hang on - are you confusing CONFIG_MODULE_SIG with CONFIG_MODVERSIONS?