Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751371AbdHFReP (ORCPT ); Sun, 6 Aug 2017 13:34:15 -0400 Received: from mail-it0-f53.google.com ([209.85.214.53]:34961 "EHLO mail-it0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751300AbdHFReO (ORCPT ); Sun, 6 Aug 2017 13:34:14 -0400 MIME-Version: 1.0 In-Reply-To: <878tixxk2j.fsf@rustcorp.com.au> References: <20170804180751.14896-1-mjg59@google.com> <878tixxk2j.fsf@rustcorp.com.au> From: Matthew Garrett Date: Sun, 6 Aug 2017 10:34:13 -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: 1005 Lines: 19 On Sat, Aug 5, 2017 at 11:54 PM, Rusty Russell wrote: > Matthew Garrett writes: >> Distributions may wish to provide kernels that permit loading of >> unsigned modules based on certain policy decisions. > > Sorry, that's way too vague to accept this patch. > > So I'm guessing a binary module is behind this vagueness. If you want > some other method than signing to vet modules, please do it in > userspace. You can do arbitrary things that way... 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, 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.