Message ID | 20230801173544.1929519-6-hch@lst.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:918b:0:b0:3e4:2afc:c1 with SMTP id s11csp2840076vqg; Tue, 1 Aug 2023 11:01:40 -0700 (PDT) X-Google-Smtp-Source: APBJJlGnfEPmynrKZA08EMuYBWFSeLGnkPL/jGWLUaGkwEZfQfdhpohv100E3tsKSDHVR4LsJVCe X-Received: by 2002:a17:90a:d78d:b0:268:1f64:cefc with SMTP id z13-20020a17090ad78d00b002681f64cefcmr10198600pju.49.1690912899750; Tue, 01 Aug 2023 11:01:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690912899; cv=none; d=google.com; s=arc-20160816; b=n+HmyEdt3BLhxfUioVYoumRDqtmJWGinXogXysUYamCgZoa4Ozc/nwJjqsmgkhYet2 kUkM6f8KXIlf2eihf2N2RPcQUSofdXWMMjWZUYQXQedxFlnfKz2ApaakL3jZd1qB4YQe sfllWHMRhMkOOpehcSqcl8YzaS61pdfZxkoBd5l9Z2amw9H8WMyVZhdNNB1vkjjBQacE GUGSn2IzFhBpX2hhvZt66PuouzqZkVvXk12RQHfVhOau04NKz02BF7gl6YTmM2R16EAn 3/g0ZCLUfxoOr7jleEC5ZMsuecC9ZpaCDBGKkBNKrQq3SU0I0TSOAfCJI+ypSXO6Ez1d l0Uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=PTHF39oHMx6VE63jxRUT6IwF0t0yHHtHwutR/mCVCgk=; fh=5HI8xClRuvQgfwG5XWQ/y0OxSazXgHJWeupfevDts70=; b=MESGVrNxcyUr4eenOgGTfOWVcCw8OhxIh12XPN9KS6Qn9weefyuJGlbteEHUQMStjw EevMqU3O4gYSJkL82Ed1AdGPDoRno0xzwuWrdlCCPz/jzBGnNmxGRON2sPvghYKERqM1 cEH1EqtgND8yVsSdPxJ/m0ybcS73zpDbIhAZKoJz0sJcf5D8T6m4dMQWTfZC/7knIwxY vfDRMly4FpnQHQEQyRChTVZQMohq5rKhKqWlP98p+xyHALFBIZ6CLaierrNj3AW0QXZL eJk1uWW9jTOWDnSTNm6NCyu6YN5hsdpBMEnnVdyIv5OLRcEG8ep4b00DXsltcldm3bLM WsPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=zqR2EJf6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qe6-20020a17090b4f8600b00267b910cb37si9673698pjb.52.2023.08.01.11.01.10; Tue, 01 Aug 2023 11:01:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=zqR2EJf6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234776AbjHARgv (ORCPT <rfc822;dengxinlin2429@gmail.com> + 99 others); Tue, 1 Aug 2023 13:36:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40464 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234173AbjHARgr (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 1 Aug 2023 13:36:47 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B4C12134; Tue, 1 Aug 2023 10:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-Type:Content-ID:Content-Description; bh=PTHF39oHMx6VE63jxRUT6IwF0t0yHHtHwutR/mCVCgk=; b=zqR2EJf6+QTJmNUjyd3x0q6VcD ookMmvswLITB4Jwjk0MzoEC2//VVIl16IMmOdtw8pgr1kY1MwZL6U6AOZIBFFwiCF7ghOcm9SgAI0 +bo9tllXEGcJ55aRFgRP9B4/c8jP8VCpTKkpQTFZy2cFUe2js6CJfRLo3txY8v8D40XRsYSIxKJcn 1Uwti/Y1q7HPJbxFDrVKbPiFrvSsj3aKT4OIT4NtRe2rUusv8THcOd9P+9zyffsUBp1BV4WrS7SGR 20yCBxxMRBrcvJKUGpgILWIlRSfpEUrtsxOQo0tVHo7wsk7OJWPZopRm0Y7a3EkUYdAXcp8pTUIZd PI9bvn8w==; Received: from 2a02-8389-2341-5b80-39d3-4735-9a3c-88d8.cable.dynamic.v6.surfer.at ([2a02:8389:2341:5b80:39d3:4735:9a3c:88d8] helo=localhost) by bombadil.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1qQtIM-002w9v-03; Tue, 01 Aug 2023 17:36:30 +0000 From: Christoph Hellwig <hch@lst.de> To: Luis Chamberlain <mcgrof@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Daniel Mack <daniel@zonque.org>, Haojian Zhuang <haojian.zhuang@gmail.com>, Robert Jarzmik <robert.jarzmik@free.fr>, Ulf Hansson <ulf.hansson@linaro.org>, Manuel Lauss <manuel.lauss@gmail.com>, Yangbo Lu <yangbo.lu@nxp.com>, Joshua Kinard <kumba@gentoo.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org (open list), linux-mmc@vger.kernel.org, netdev@vger.kernel.org, linux-rtc@vger.kernel.org, linux-modules@vger.kernel.org Subject: [PATCH 5/5] modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules Date: Tue, 1 Aug 2023 19:35:44 +0200 Message-Id: <20230801173544.1929519-6-hch@lst.de> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230801173544.1929519-1-hch@lst.de> References: <20230801173544.1929519-1-hch@lst.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773050685126690242 X-GMAIL-MSGID: 1773050685126690242 |
Series |
[1/5] ARM: pxa: remove use of symbol_get()
|
|
Commit Message
Christoph Hellwig
Aug. 1, 2023, 5:35 p.m. UTC
It has recently come to my attention that nvidia is circumventing the protection added in 262e6ae7081d ("modules: inherit TAINT_PROPRIETARY_MODULE") by importing exports from their proprietary modules into an allegedly GPL licensed module and then rexporting them. Given that symbol_get was only ever intended for tightly cooperating modules using very internal symbols it is logical to restrict it to being used on EXPORT_SYMBOL_GPL and prevent nvidia from costly DMCA Circumvention of Access Controls law suites. All symbols except for four used through symbol_get were already exported as EXPORT_SYMBOL_GPL, and the remaining four ones were switched over in the preparation patches. Fixes: 262e6ae7081d ("modules: inherit TAINT_PROPRIETARY_MODULE") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- kernel/module/main.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
Comments
On Tue, 2023-08-01 at 19:35 +0200, Christoph Hellwig wrote: > It has recently come to my attention that nvidia is circumventing the > protection added in 262e6ae7081d ("modules: inherit > TAINT_PROPRIETARY_MODULE") by importing exports from their proprietary > modules into an allegedly GPL licensed module and then rexporting them. > > Given that symbol_get was only ever intended for tightly cooperating > modules using very internal symbols it is logical to restrict it to > being used on EXPORT_SYMBOL_GPL and prevent nvidia from costly DMCA > Circumvention of Access Controls law suites. I'm all for insisting that everything be exported with EXPORT_SYMBOL_GPL and nothing at all ever be exported with just EXPORT_SYMBOL. But if we're going to tolerate the core kernel still exporting some stuff with EXPORT_SYMBOL, why isn't OK for a GPL-licensed module do to the same? Even an *in-tree* GPL-licensed module now can't export functionality with EXPORT_SYMBOL and have it used with symbol_get(). We're forced to *either* allow direct linking by non-GPL modules, or allow symbol_get(), but not both? > Fixes: 262e6ae7081d ("modules: inherit TAINT_PROPRIETARY_MODULE") Hm, the condition we really need to fix *that* is "symbol_get() will only import symbols from GPL-licensed modules", isn't it? As long as that property is correctly transitive, why does the symbol itself have to be EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL? Am I missing another potential loophole? I suppose there's now scope for a different type of shim which *directly* imports an EXPORT_SYMBOL function in order to export it again as EXPORT_SYMBOL_GPL and thus allow the GPL export to be found with symbol_get()? That's the *converse* of the problematic shim that was being used before, and from a licensing point of view it seems fine... it's just working around the unintended side-effects of this patch?
On Wed, Oct 18, 2023 at 01:30:18AM +0100, David Woodhouse wrote: > > But if we're going to tolerate the core kernel still exporting some > stuff with EXPORT_SYMBOL, why isn't OK for a GPL-licensed module do to > the same? Even an *in-tree* GPL-licensed module now can't export > functionality with EXPORT_SYMBOL and have it used with symbol_get(). Anything using symbol_get is by intent very deeply internal for tightly coupled modules working together, and thus not a non-GPL export. In fact the current series is just a stepping stone. Once some mess in the kvm/vfio integration is fixed up we'll require a new explicit EXPORT_SYMBOL variant as symbol_get wasn't ever intended to be used on totally random symbols not exported for use by symbol_get.
On Wed, Oct 18, 2023 at 07:31:46AM +0200, Christoph Hellwig wrote: > On Wed, Oct 18, 2023 at 01:30:18AM +0100, David Woodhouse wrote: > > > > But if we're going to tolerate the core kernel still exporting some > > stuff with EXPORT_SYMBOL, why isn't OK for a GPL-licensed module do to > > the same? Even an *in-tree* GPL-licensed module now can't export > > functionality with EXPORT_SYMBOL and have it used with symbol_get(). > > Anything using symbol_get is by intent very deeply internal for tightly > coupled modules working together, and thus not a non-GPL export. > > In fact the current series is just a stepping stone. Once some mess > in the kvm/vfio integration is fixed up we'll require a new explicit > EXPORT_SYMBOL variant as symbol_get wasn't ever intended to be used > on totally random symbols not exported for use by symbol_get. The later patches in the series also show we could resolves most uses through Kconfig and at build time, it really begs the question if we even need it for any real valid uses. Luis
diff --git a/kernel/module/main.c b/kernel/module/main.c index 59b1d067e52890..c395af9eced114 100644 --- a/kernel/module/main.c +++ b/kernel/module/main.c @@ -1295,12 +1295,20 @@ void *__symbol_get(const char *symbol) }; preempt_disable(); - if (!find_symbol(&fsa) || strong_try_module_get(fsa.owner)) { - preempt_enable(); - return NULL; + if (!find_symbol(&fsa)) + goto fail; + if (fsa.license != GPL_ONLY) { + pr_warn("failing symbol_get of non-GPLONLY symbol %s.\n", + symbol); + goto fail; } + if (strong_try_module_get(fsa.owner)) + goto fail; preempt_enable(); return (void *)kernel_symbol_value(fsa.sym); +fail: + preempt_enable(); + return NULL; } EXPORT_SYMBOL_GPL(__symbol_get);