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] [day] [month] [year] [list]
Message-ID: <0abfc041-571b-75ae-0d53-48f801aab043@canonical.com>
Date:   Fri, 18 Jun 2021 11:41:11 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Christoph Hellwig <hch@....de>, Jessica Yu <jeyu@...nel.org>
Subject: Re: [PATCH 5.4 031/184] modules: inherit TAINT_PROPRIETARY_MODULE

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@....de>
>>>>>
>>>>> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ