Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751298AbdH2R4x (ORCPT ); Tue, 29 Aug 2017 13:56:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:34240 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751227AbdH2R4w (ORCPT ); Tue, 29 Aug 2017 13:56:52 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C68632199E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=jeyu@kernel.org Date: Tue, 29 Aug 2017 19:56:47 +0200 From: Jessica Yu To: Matthew Garrett Cc: linux-kernel@vger.kernel.org, Rusty Russell Subject: Re: Allow automatic kernel taint on unsigned module load to be disabled Message-ID: <20170829175647.ej5fqszss2mbpc5i@redbean> References: <20170804180751.14896-1-mjg59@google.com> <20170810204328.kk4lbj4hvednmofw@redbean> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-OS: Linux redbean 4.12.8-300.fc26.x86_64 x86_64 User-Agent: NeoMutt/20170714 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1375 Lines: 33 +++ Matthew Garrett [14/08/17 12:50 -0400]: >On Thu, Aug 10, 2017 at 4:43 PM, Jessica Yu wrote: >> I think I'm missing some context here. Could you provide some more >> background and help me understand why we want to go into all this >> trouble just to avoid a taint? Was there a recent bug report, mailing >> list discussion, etc. that spurred you to write this patch? I'm not >> understanding why this particular taint is undesirable. > >Hi Jessica, > >Does the version in https://lkml.org/lkml/2017/8/7/764 make this clearer? Hi Matthew, Sorry for the delay, I'm currently on leave traveling. I understand what the patch is doing, what I don't yet understand is _why_ you would want to remove the unsigned module taint when CONFIG_MODULE_SIG is enabled. Which distributions are asking for this exactly, and for what use cases? I find it a bit contradictory to have CONFIG_MODULE_SIG enabled and at the same time expect the kernel to behave as if the option wasn't enabled. I would really prefer not to add extra code to remove what is cosmetic and still has informational/debug value. If the unsigned module taint is for whatever reason that bothersome, why can't distro(s) carry a 2-line patch removing the message and taint for those particular setups where signatures are considered "irrelevant" even with CONFIG_MODULE_SIG=y? Thanks, Jessica