Re: [PATCH 5.4 031/184] modules: inherit TAINT_PROPRIETARY_MODULE

[Krzysztof Kozlowski]

On 18/06/2021 11:29, Greg Kroah-Hartman wrote:
> On Fri, Jun 18, 2021 at 11:22:37AM +0200, Krzysztof Kozlowski wrote:
>> On 18/06/2021 11:19, Greg Kroah-Hartman wrote:
>>> On Fri, Jun 18, 2021 at 10:57:23AM +0200, Krzysztof Kozlowski wrote:
>>>> On 10/05/2021 12:18, Greg Kroah-Hartman wrote:
>>>>> From: Christoph Hellwig <hch@xxxxxx>
>>>>>
>>>>> commit 262e6ae7081df304fc625cf368d5c2cbba2bb991 upstream.
>>>>>
>>>>> If a TAINT_PROPRIETARY_MODULE exports symbol, inherit the taint flag
>>>>> for all modules importing these symbols, and don't allow loading
>>>>> symbols from TAINT_PROPRIETARY_MODULE modules if the module previously
>>>>> imported gplonly symbols.  Add a anti-circumvention devices so people
>>>>> don't accidentally get themselves into trouble this way.
>>>>>
>>>>> Comment from Greg:
>>>>>   "Ah, the proven-to-be-illegal "GPL Condom" defense :)"
>>>>
>>>> Patch got in to stable, so my comments are quite late, but can someone
>>>> explain me - how this is a stable material? What specific, real bug that
>>>> bothers people, is being fixed here? Or maybe it fixes serious issue
>>>> reported by a user of distribution kernel? IOW, how does this match
>>>> stable kernel rules at all?
>>>>
>>>> For sure it breaks some out-of-tree modules already present and used by
>>>> customers of downstream stable kernels. Therefore I wonder what is the
>>>> bug fixed here, so the breakage and annoyance of stable users is justified.
>>>
>>> It fixes a reported bug in that somehow symbols are being exported to
>>> modules that should not have been.  This has been in mainline and newer
>>> stable releases for quite some time, it should not be a suprise that
>>> this was backported further as well.
>>
>> This is vague. What exactly is the bug? How exporting symbols which
>> should not be exported, causes it? Is there OOPs? Some feature does not
>> work?
> 
> The bug/issue is that symbols were being incorrectly exported in ways
> that they should not have been and were available to users that should
> not have been able to use them.  That is what this patch series
> resolves.  I can go into details but they are boring and deal with
> closed source monstrosities that feel they are allowed to muck around in
> kernel internals at will, which causes a support burden on the kernel
> community.

Thanks Greg, I would prefer honest "we don't want others to do something
we don't like or approve and we can change it" :)

> If you object to this, that's fine, you are free to revert them in your
> local distro kernel after discussing it with your lawyers to get their
> approval to do so.


Best regards,
Krzysztof