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]
Message-ID: <20190110131321.GD20217@kroah.com>
Date:   Thu, 10 Jan 2019 14:13:21 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Marc Dionne <marc.c.dionne@...il.com>
Cc:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        x86@...nel.org
Subject: Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

On Wed, Jan 09, 2019 at 01:40:14PM -0400, Marc Dionne wrote:
> On Wed, Jan 9, 2019 at 1:09 PM Sebastian Andrzej Siewior
> <bigeasy@...utronix.de> wrote:
> >
> > On 2019-01-09 17:52:35 [+0100], Greg Kroah-Hartman wrote:
> > > If there are no in-kernel users, the symbols should not be exported
> > > anymore.  That's nothing new, we have always done this.
> >
> > The thing is that we had
> >   EXPORT_SYMBOL(__kernel_fpu_begin)
> >   EXPORT_SYMBOL_GPL(kernel_fpu_begin)
> >
> > and now __kernel_fpu_begin() is no longer exported and static only.
> > All in kernel user (including the kvm module) use kernel_fpu_begin()
> > which is not available to proprietary modules. Hence Marc's mail.
> >
> > > > On the other hand could we just drop EXPORT_SYMBOL_GPL? I doubt this
> > > > helps in any way yet please correct me if I am wrong.
> > >
> > > Yes, it helps, please leave it as-is.
> >
> > As you say. I only notice that certain things used to work and then no
> > longer do because due to $rework it somehow become EXPORT_SYMBOL_GPL
> > only and people complain and we tend to switch the export back to
> > EXPORT_SYMBOL. I'm not aware of a case where it actually helped in
> > anyway.
> >
> > > thanks,
> > >
> > > greg k-h
> >
> > Sebastian
> 
> I would point out that there are several precedents for restoring
> exports after functionality has been unintentionally made GPL only;
> from a quick lookup these are some examples:
> 
>   8af190958059 ("x86/paravirt: Remove GPL from pv_ops export")
>   31c5bda3a656 ("mm: fix exports that inadvertently make put_page()
> EXPORT_SYMBOL_GPL")
>   1e5476815fd7 ("x86/tlb: Drop the _GPL from the cpu_tlbstate export")
>   b562c171cf01 ("locking/refcounts: Do not force refcount_t usage as
> GPL-only export")

Yes, but this is a bit different of a thing here.  The symbol you wish
to have changed was not modified at all, you just lost access to an
internal function that was fixed up and removed.

Best of luck,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ