linux-kernel - Re: [PATCH] x86/fpu: Remove the _GPL from the 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]

Date:   Fri, 3 May 2019 20:07:39 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Greg KH <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Rik van Riel <riel@...riel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Nicolai Stange <nstange@...e.de>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>, X86 ML <x86@...nel.org>,
        stable <stable@...r.kernel.org>
Subject: Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end()
 export

On Fri, May 03, 2019 at 11:21:15AM -0600, Paolo Bonzini wrote:
> Your observation that the API only exists on x86 and s390 has no bearing
> to whether the functions should be EXPORT_SYMBOL_GPL or EXPORT_SYMBOL.
> ARM has kernel_neon_begin/end, PPC has enable/disable_kernel_altivec.
> It's just that SIMD code is so arch-specific that nobody has bothered
> unifying the namings (or, nobody considers the different names a problem
> at all).

This is actually proving my point: there wasn't any real agreement on
what interfaces should be immutable so that out-of-tree code can use
them and us guaranteeing they won't change. Instead, it was a random
thing that just happened.

So if you have to use them in some out-of-tree module, you'd have to
do arch-specific hackery, obviously, because each arch does different
things.

So what happened is that out-of-tree module simply grabbed them and now
when we change our implementation, we broke it. And I care about this
why exactly?

So let me cut to the chase: you and Andy are arguing about what exactly?

* We should support out-of-tree code in general?

* We should support out-of-tree code if/when <fill in the specifics which
out-of-tree code should be supported by Linux and which not>?

* We should be free to change kernel interfaces and implementation as
we see fit, without paying attention to some out-of-tree, probably
license-incompatible, maybe even proprietary code? (I don't think it is
that, though).

* Something else I've missed.

So before we waste any more time with this, let's agree on the rules
first: do we support out-of-tree code and if so, how much and to what
degree?

This keeps happening so I think we should write it all down so that it
is crystal clear to all parties involved what can and cannot be done.
And then when we all agree, we can enforce those rules and then act
accordingly when changing implementations.

Maybe it is written down somewhere but I haven't found it yet so if you
do, pls point me to it.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.