Received: by 10.223.185.116 with SMTP id b49csp659407wrg; Fri, 16 Feb 2018 05:13:48 -0800 (PST) X-Google-Smtp-Source: AH8x227kp8HA2Yj7huHNGz16OsyeeO34jmIzBFzD9FUF9L7Vk0gvgMQuhwfZ4K4YQhnLTXRuwRsN X-Received: by 10.98.150.213 with SMTP id s82mr6155034pfk.10.1518786828225; Fri, 16 Feb 2018 05:13:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518786828; cv=none; d=google.com; s=arc-20160816; b=oMvGHklwpfbQfXOH9lMuxiqUA2+UQ2svimVbin1upQvWaoD5U68euZ025HyzGczGvX tcCLRjpXbVALnj4kU+F0EFIU0fPMbjyD774h13n86C2cu1JmDxkKG0uXHjSSHNpsSU/o KeL2BU0Gr+FXeOadgSfqDpa+BczOq/H/yvh1NlTX8XDVxS2Jw5TtWxV3XWDwlnsfp2HK rskW2KXsXrla2ptOW9kk59W6BiBtcNN8rvFpQedbUlM7Jl+hZWNlL3G2NLc60APwgvrb Oh0+p7R8LaQo28gFADlbOsXqDn1fVOmCC4kUCWVWqAakRQlXpWSezufyDl9umcPV7uTs +uyg== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:dmarc-filter:arc-authentication-results; bh=IgqKDyFATdz8Kd+1FaYkb4CuIQfkpoAqFZpt5NX1Yv8=; b=l3jZez7ippFjNjtSmPEr/HyqkxESqfjeIKUyB+rul41DxTJjV7TnogWfjs/sTbE/QR FTAndqoeGRF7y7sri4xr5HN3mLfSadDlqew54OxuT0cxGKEmEtK/3EVEUFTZ/spHiLCR lfOEQFi5EwwLfp7wTPmYxiPTD7zcz5a6JTEuLzfgqotPMW1Ei5E7M5QhVm64+Red+moI hqga31xwCGhf2/vOmbZfORtYyKAaNqczvToYDk1QCwFVE/qHvv5+ZdOrqLp2O2X1pa8B 6UqPLBIC335BshLIV2mjcukWcfCXadL36tCvvA0qEdhHD1puet0gjrPb8katdLhTYfT9 1RAQ== 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 z8si4608019pfk.414.2018.02.16.05.13.33; Fri, 16 Feb 2018 05:13:48 -0800 (PST) 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 S1166496AbeBOS3D (ORCPT + 99 others); Thu, 15 Feb 2018 13:29:03 -0500 Received: from mail.kernel.org ([198.145.29.99]:54508 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1163160AbeBOPZV (ORCPT ); Thu, 15 Feb 2018 10:25:21 -0500 Received: from redbean (ip5f5adea9.dynamic.kabel-deutschland.de [95.90.222.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CF4C9217A0; Thu, 15 Feb 2018 15:25:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF4C9217A0 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: Thu, 15 Feb 2018 16:25:16 +0100 From: Jessica Yu To: Matthew Garrett Cc: Ben Hutchings , Linux Kernel Mailing List Subject: Re: [PATCH] Make kernel taint on invalid module signatures configurable Message-ID: <20180215152514.rxmh7webdg2i2fct@redbean> References: <20170807195027.13192-1-mjg59@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-OS: Linux redbean 4.14.16-200.fc26.x86_64 x86_64 User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +++ Matthew Garrett [14/02/18 18:21 +0000]: >Hi Jessica, > >Any objections to this patch? > >Thanks! Hi Matthew! My questions and comments from last year still apply here - http://lkml.kernel.org/r/20170829175647.ej5fqszss2mbpc5i@redbean I'm still unclear on why a distro would enable CONFIG_MODULE_SIG and then _not_ want to know about unsigned modules. From what I understand from Ben's post from last year (http://lkml.kernel.org/r/1504044122.4448.24.camel@decadent.org.uk), it sounds like the main issue is that Debian doesn't support their own centralised module signing yet, causing all of their modules to be automatically tainted if they enable CONFIG_MODULE_SIG, and that a new option like this would likely be used as a temporary "fix". Am I understanding correctly? I understand this predicament, but it seems like adding a new set of options/parameters like this is just hiding the symptoms of the problem (modules distributed by Debian getting tainted by default) instead of fixing what seems to be the heart of the issue (Debian doesn't support their own module signing yet), if that makes sense. I am hesitant about merging something that would only serve as a temporary solution until Debian supports their own module signing. In that case, I would prefer the Debian folks to maintain their own patch removing the taint until they support module signing for their own modules, especially if - and please correct me if I'm wrong - the new option is not going to see long-term usage. Thanks, Jessica