linux-kernel - Re: [PATCH v4] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR

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] [day] [month] [year] [list]

Message-ID: <168098e4-a5f1-4b51-8216-7adee9959ba9@suse.cz>
Date: Tue, 19 Aug 2025 22:44:11 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: David Hildenbrand <david@...hat.com>, Daniel Gomez
 <da.gomez@...sung.com>, Linus Torvalds <torvalds@...ux-foundation.org>,
 Matthias Maennich <maennich@...gle.com>, Jonathan Corbet <corbet@....net>,
 Luis Chamberlain <mcgrof@...nel.org>, Petr Pavlu <petr.pavlu@...e.com>,
 Sami Tolvanen <samitolvanen@...gle.com>,
 Nathan Chancellor <nathan@...nel.org>,
 Nicolas Schier <nicolas.schier@...ux.dev>,
 Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>
Cc: Christoph Hellwig <hch@...radead.org>,
 Peter Zijlstra <peterz@...radead.org>, Shivank Garg <shivankg@....com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 "Jiri Slaby (SUSE)" <jirislaby@...nel.org>,
 Stephen Rothwell <sfr@...b.auug.org.au>, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-modules@...r.kernel.org,
 linux-kbuild@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v4] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to
 EXPORT_SYMBOL_FOR_MODULES

On 8/8/25 4:17 PM, David Hildenbrand wrote:
> On 08.08.25 15:28, Vlastimil Babka wrote:
>> Christoph suggested that the explicit _GPL_ can be dropped from the
>> module namespace export macro, as it's intended for in-tree modules
>> only. It would be possible to restrict it technically, but it was
>> pointed out [2] that some cases of using an out-of-tree build of an
>> in-tree module with the same name are legitimate.
> 
> I'm wondering if we could revisit that idea later, and have a config
> option that enables that. The use cases so far were mostly around
> testing IIRC, where people already run their own debug kernel or sth.
> like that.

I don't know. It made sense to do this in-tree restriction when it
looked like it could be done unconditionally. But if it would need to be
opt-in config, I think there's little gain. As noted in the lwn
coverage, the metadata can be easily faked anyway. AFAIK the only
serious module loading restriction is then the module signing, so this
would be just a mostly pointless config option?