linux-kernel - Re: [RFC PATCH 6/9] memory: apple: Add apple-mcc driver to manage MCC perf in Apple SoCs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <839339f3-7c12-32aa-cd37-e91d824cfdbe@marcan.st>
Date:   Thu, 14 Oct 2021 17:31:25 +0900
From:   Hector Martin <marcan@...can.st>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Sven Peter <sven@...npeter.dev>, Marc Zyngier <maz@...nel.org>,
        Mark Kettenis <mark.kettenis@...all.nl>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Catalin Marinas <catalin.marinas@....com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Kevin Hilman <khilman@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 6/9] memory: apple: Add apple-mcc driver to manage MCC
 perf in Apple SoCs

On 14/10/2021 17.04, Krzysztof Kozlowski wrote:
>> It is; only modules with a GPL-compatible MODULE_LICENSE get to use
>> symbols exported via EXPORT_SYMBOL_GPL.
> 
> Although there might be such correlation but it's not a rule. You can
> have a GPL module exporting symbols without GPL requirement
> (EXPORT_SYMBOLS). You can have a GPL+MIT module exporting symbols as
> GPL. Obviously you cannot have a non-GPL module, as we do not accept
> these and there is no such choice.

What I mean is that modules can only import GPL symbols if they 
themselves are GPL compatible. What I didn't know is that "Dual MIT/GPL" 
is a valid string for MODULE_LICENSE to qualify as such.

>> See kernel/module.c for the symbol lookup logic and
>> include/linux/license.h for the logic to check the string (seems like
>> "Dual MIT/GPL" is explicitly whitelisted there).
> 
> Not related to export symbol. It is used for determining the tainted
> kernel via other licenses.
> 

Not just that; that module taint is used as a filter so that 
non-GPL-compatible modules are technically prevented from resolving 
EXPORT_SYMBOL_GPL symbols.

>> Of course, this is a futile effort, as ~every time I see a proprietary
>> module in some embedded device, it either falsely declares itself to be
>> GPL, or they have a shim module that re-exports GPL symbols as non-GPL.
>>
> 
> This is being removed soon (or already).

? Good luck getting proprietary embedded vendors to start following 
licenses... :)

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub