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>] [day] [month] [year] [list]

Date:   Thu, 10 Jan 2019 19:07:13 -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 Thu, Jan 10, 2019 at 07:07:52PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2019-01-10 17:32:58 [+0000], Hutter, Tony wrote:
> > > > But since when did out-of-tree modules use __kernel_fpu_begin? 
It's an
> > > > x86-only thing, and shouldn't really be used by anyone, right?
> > >
> > > ZFS on Linux uses it for checksums.  Its removal is currently
breaking ZFS builds against 5.0:
> >
> > So btrfs uses crc32c() / kernel's crypto API for that and ZFS can't?
> > Well the crypto API is GPL only exported so that won't work. crc32c() is
> > EXPORT_SYMBOL() so it would work.
> > On the other hand it does not look right to provide a EXPORT_SYMBOL
> > wrapper around a GPL only interfaceâ€¦

> Yes, the "GPL condom" attempt doesn't work at all.  It's been shot down
> a long time ago in the courts.

SFLC maintains there is no kernel licensing issue[1].

As a side note, even Hellwig's suit against VMware was dismissed (he may
appeal)[2].

Debian and Canonical base their decision to ship DKMS source for ZFS on
Linux[3].

The GPL does not disqualify a user from compiling ZFS or Linux however
they see fit.
It is only the users' distribution rights that come into question.

No one is combing ZFS into Linux or even distributing binary modules here;
we're following the terms of GPL.

> My tolerance for ZFS is pretty non-existant.  Sun explicitly did not
> want their code to work on Linux, so why would we do extra work to get
> their code to work properly?

1. Should your personal feelings affect the quality of the Linux kernel?
I say no.

2. Did Sun or Oracle ever release any statement of any kind that backs
your statement?

3. What extra work is being done here aside from the dropping of a
pseudo-protection,
the "GPL ONLY" symbol export? Something tells me, even if someone else
did "the work"
and submitted patches, you would find a reason to tell them to get
stuffed and leave
it "as-is".

With all of that... why have ANY kind of tolerance for out of tree
kernel modules at all?

[1] https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html

[2] https://opensource.com/law/16/8/gpl-enforcement-action-hellwig-v-vmware

[3] https://lists.debian.org/debian-devel-announce/2015/04/msg00006.html

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