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 11:54:54 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        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 May 3, 2019, at 11:07 AM, Borislav Petkov <bp@...en8.de> wrote:
> 
>> 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.
> 

I don’t think I or has said we should try to make these interfaces immutable. What I’m saying is that, since we’re exporting the symbol anyway and it’s not particularly Linuxy, that we shouldn’t say that only *GPL* out-of-tree modules may use it.  It seems like anyone who wants to put the effort into tracking which kernel has which symbols and is willing to accept the utter instability of the interface may use it.

So if we ever unexport the symbol entirely, I won’t object.  I object to what I consider to be the inappropriate claim that it’s a *GPL* export.

(I actually hope we unexport it once simd_get() and friends land — they’re a much better API, and we should migrate over to it.)