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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190503190751.GG5020@zn.tnic>
Date:   Fri, 3 May 2019 21:07:51 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Andy Lutomirski <luto@...capital.net>
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 Fri, May 03, 2019 at 11:54:54AM -0700, Andy Lutomirski wrote:
> I don’t think I or has said we should try to make these interfaces
> immutable.

How else would you have a stable interface for OOT modules? If at all,
that is.

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

This is just silly: when we change it next time, it'll be the same
crying again. No, we don't want to do that. This keeps happening with
all kinds of symbols being exported and unexported.

> So if we ever unexport the symbol entirely, I won’t object.

Yah, and you'll break them again. That's just unnecesary pain each time.

> I object to what I consider to be the inappropriate claim that it’s
> a *GPL* export.

Yes, that is the problem. Jiri alluded to it too - I don't think it is
clear to people involved - me included - what exports should be done and
how. And what assurances - if any - we're giving.

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

Same problem as above with those.

That's why we need some sort of an explicit ruling all sides will adhere
to.

-- 
Regards/Gruss,
    Boris.

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