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:21:15 -0600
From:   Paolo Bonzini <>
To:     Borislav Petkov <>, Andy Lutomirski <>
Cc:     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()

On 02/05/19 10:55, Borislav Petkov wrote:
> On Thu, May 02, 2019 at 09:29:01AM -0700, Andy Lutomirski wrote:
>> I'm not saying that we should export things for ZFS's benefit.  But,
>> as far as I know, _GPL means "this interface is sufficiently specific
>> to Linux details that we think that any user must be a derived work".
>> I don't think that kernel_fpu_begin() is an example of that.
> But it is sufficiently specific. It is present on x86 and s390 only -
> other arches don't have it.

This is not what is meant usually by "sufficiently specific to Linux
details".  The questions to ask are:

1) Is it a Linux-only thing to run FPU or SIMD code in the kernel?  The
answer is clearly no.

2) Is the API form tied to Linux's implementation of the FPU?  I'd argue
that a simple begin/end pair is not (for example, on Windows you just
xsave at the beginning and xrstor at the end).

So I totally agree with Andy on this.

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).


Powered by blists - more mailing lists