Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp610905pxa; Fri, 31 Jul 2020 23:55:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwhDQotnY91jE7kxBW2QiHX5FLNwbuUFTMcMoPDDS+qFdAI0vLyLwNiH9kjnQ0rja2Q6TNn X-Received: by 2002:a17:906:65b:: with SMTP id t27mr7815316ejb.457.1596264914133; Fri, 31 Jul 2020 23:55:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596264914; cv=none; d=google.com; s=arc-20160816; b=LUGvWSe+M1hE8XiFXTBmYb09UgLouZs6NRdK1XZ9q+zAgOhWO3Be3EAIdSUKnDdcZA Io5lkU5LLWcbTu25RtdQGRHzMwoI/aCV0i8S2u7RntWWMpmvOYyBzEnosmZHNSfPIEX2 R6rw5tVZHAIpTIxKjIu0Cl8+22RuwDr9sjFkbookm6lq9WxGTvCaazzQ7UB3VVlLN54i khAVh0Qov0f5XaTCALI85qiokqCZgbwclHRuA9KV2SxaDUU3LfTHTFNK7NHb9S5aXNcK 6wvVokzJKP33YP+U/3Kcr99nF0wVb8lWBu62hAkPY14VBC+CcS6D3Ue7dzECtDA9/DLU 4usA== 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; bh=3iWDsiAWgUpaZIAP8RBmx3C3Gc9Cr2LFWLcMqDeSnf0=; b=Gjir6AKrnQOIDmgvtNwr8E6auQbdMnvrJE6osd1h4pWdQ28vlqwMRcBo7Q6sVJN0wm okBy4upbFzarexbzzNc3SxdS9KRTB5SbWzSnh7U+OeFEitwe8WFnxhxcrr6NAgp/GdB/ e1RajdK7GVUlHigOD+L08cISSPntWR2//Sxf0yaan6tuigrSGFzRRhE3IrkgeI9muDE5 3CjPw3fjg6DoQeVt4kCxXZtZa0UR0XJZnSlrq4asIjLweTeyOV0OWfbap/aBZf8K7Br/ EvIQNnp1ByiQLINv720Tp0uXqAXvVQjqcv7EjCQ4EZKGewnBJKKZgjCpnuQk3/ZpeahZ 4AQw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r20si6619896ejz.158.2020.07.31.23.54.51; Fri, 31 Jul 2020 23:55:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726400AbgHAGxL (ORCPT + 99 others); Sat, 1 Aug 2020 02:53:11 -0400 Received: from verein.lst.de ([213.95.11.211]:33384 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725283AbgHAGxL (ORCPT ); Sat, 1 Aug 2020 02:53:11 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id C9ECF68BFE; Sat, 1 Aug 2020 08:53:08 +0200 (CEST) Date: Sat, 1 Aug 2020 08:53:08 +0200 From: Christoph Hellwig To: josh@joshtriplett.org Cc: Greg Kroah-Hartman , Jessica Yu , linux-kernel@vger.kernel.org Subject: Re: inherit TAINT_PROPRIETARY_MODULE v2 Message-ID: <20200801065308.GA1930@lst.de> References: <20200730061027.29472-1-hch@lst.de> <20200731201146.GA34345@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200731201146.GA34345@localhost> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [note: private reply now to start a flame fest with the usual suspects] On Fri, Jul 31, 2020 at 01:11:46PM -0700, josh@joshtriplett.org wrote: > Christoph Hellwig wrote: > > we've had a bug in our resolution of _GPL modules since day one, that > > is a module can claim to be GPL licensed and use _GPL exports, while > > it also depends on symbols from non-GPL modules. This is used as a > > circumvention of the _GPL exports by using a small shim module using > > the _GPL exports and the other functionality. > > This looks great. You might also consider doing the reverse: if a module > imports any EXPORT_SYMBOL_GPL symbols, any symbols that module in turn > exports shouldn't be importable by any module that doesn't explicitly > claim to be GPL-compatible. Effectively, if a module imports any > EXPORT_SYMBOL_GPL symbols, all of its exported symbols would then be > treated as EXPORT_SYMBOL_GPL. > > This would catch the case of attempting to "wrap" EXPORT_SYMBOL_GPL > symbols in the other direction, by re-exporting the same or similar > functions to another module. (This would help catch mistakes, not just > intentional malice.) I'd personally 100% agree with that, but I'd rather clear it with Linus privately first. This would basically make most of the usual modular subsystems unavailable to proprietary modules as all of them use _GPL driver core exports, and I suspect he'd cave into the screaming.