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 <>
To:     Borislav Petkov <>
Cc:     Paolo Bonzini <>,
        Andy Lutomirski <>,
        Sebastian Andrzej Siewior <>,
        Greg KH <>,
        LKML <>,
        Rik van Riel <>,
        "H. Peter Anvin" <>,
        "Jason A. Donenfeld" <>,
        Ard Biesheuvel <>,
        Dave Hansen <>,
        Ingo Molnar <>,
        Nicolai Stange <>,
        Radim Krčmář <>,
        Thomas Gleixner <>, X86 ML <>,
        stable <>
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 <> 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.)

Powered by blists - more mailing lists