linux-kernel - Re: x86/fpu: Don't export __kernel_fpu

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: <5fcc7fe6-9de3-cf34-075b-c17a28e85efa@tripleback.net>
Date:   Tue, 15 Jan 2019 10:51:18 -0800
From:   Kash Pande <kash@...pleback.net>
To:     linux-kernel@...r.kernel.org
Subject: Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

On 2019-01-15 5:42 a.m., Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 02:01:48PM +0100, Rene Schickbauer wrote:
>> To be frank, your argument, which boils down to "GPL is the only correct
>> open source license", makes me ashamed to have been advocating people
>> switching to Linux. This is exactly the kind of argument that made me switch
>> away from closed source operating systems like Windows, only then it was
>> Steve Ballmer using it against open source.
> What?
>
> No, my argument is, "If you want to interact directly with Linux kernel
> code in kernel-space, then you have to abide by it's license, which is
> GPLv2".  That's it.  If you wish to use open source code by another
> license, wonderful, I'm not telling you what you can, and can not do,
> but please, do not violate the license of the code I contributed under
> GPLv2.

You mean "if you want to interact directly with arbitrary Linux kernel
functionality that we deem GPL-only, then you have to abide by its license"

Because the GPL-only symbol export makes it seem like most symbols are
NOT GPL-only. Why is there any distinction at all?

Why does the Linux kernel allow loading of non-GPL modules? Maybe it's
because the end user is ALLOWED to load non-GPL modules?

ZFS is ALLOWED to exist in the Linux ecosystem. It is not ALLOWED to be
distributed with the Linux kernel in binary form. The source trees can
not be merged without patent issues. No one is debating this.

What the issue here, is that previously a non-GPL module was working,
and now is not. NVIDIA is running GPL code?

>
> ZFS could be the best filesystem ever to grace this planet, that's
> fantastic, but given that the creators of that code placed it under a
> license that was specifically designed to not be compatible with Linux
> to prevent it from ever being used on Linux, well, you can see why I
> really don't care about it.  Why would I?

Asked last week for a source on this and you haven't provided any.
However, the SFLC plainly disagrees with you.

>
> Those copyright owners (well license owner at this point in time) could
> fix this all tomorrow if they wanted to.  But they do not, so _THEY_ are
> the people you should be upset at.  Not at the Linux kernel developers
> who are giving you a kernel on which to use on your systems, for free,
> under the GPLv2.  Our position has always been very clear and upfront.
> And really, so has the ZFS license creators.  So why is anyone upset
> about all of this?  Nothing new has changed here with the license of
> anything.

The previous situation was the STATUS QUO for years. Since 2012 we had
working ZFS on Linux with SIMD extensions, and now suddenly being told
that it is a license violation.

This is why people are upset at you, because you stand here waving a big
stick and telling us that we are breaking some rule you have merely
imagined.

>
> best of luck!
>
> greg k-h
>

Message received, loud and clear. We will go back to wrapping GPL-only
exports in our SPL (GPL licensed) kernel module. The Condom Works!

Best of luck with your windmills, Don Quixote.

Kash

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)