linux-kernel - Re: genksyms vs. opaque struct *

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: <aScbH4waSxrd0KIu@derry.ads.avm.de>
Date: Wed, 26 Nov 2025 16:22:07 +0100
From: Nicolas Schier <nsc@...nel.org>
To: Philipp Hahn <phahn-oss@....de>
Cc: Masahiro Yamada <masahiroy@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: genksyms vs. opaque struct *

On Thu, Nov 13, 2025 at 09:40:11PM +0100, Philipp Hahn wrote:
> Hello,
> 
> while building a Linux kernel module I stumbled over an issue with
> 'genksyms': Basically my modules uses an "opaque struct" and only gets
> a pointer to such an object. The header file declaring that struct did
> *not* #include all needed header files recursively, so some types
> remained unresolved.
> For compiling the module this was not an issue as the compiler only
> needs to allocate space for an pointer to that nested struct and does
> not need more details.
> Another module exists which uses that symbol and recorded the
> calculated CRC.
> 
> Then I changed my module and added some more #includes, which resulted
> into `genksyms` getting *more* details on the next run while the
> implementation actually did not change.
> 
> I only found out root cause of my problem after digging into the
> genksyms-machinery myself, where I found the option `--warnings`,
> which actually prints out such a warning in my case:
> > /home/pmhahn/prog/my-modver/my-modver.c:8: expand undefined struct bar
> 
> In my example below it makes a difference if `-DDETAIL` is given or not:
> > cpp -E -D__GENKSYMS__ …my-modver.c -DDETAIL | scripts/genksyms/genksyms -r /dev/null -w
> > #SYMVER my_function 0x0cdb4509
> > cpp -E -D__GENKSYMS__ …my-modver.c  | scripts/genksyms/genksyms -r /dev/null -w
> > #SYMVER my_function 0x87675506
> 
> I wonder, why that option is not enabled by default or if there is
> another solution to prevent such breaking changed by including
> more/less #includes? Are there any good/recommended practices?

FTR:  Philipp and I had a face-to-face conversation about the topic.
Some results for possible thread readers:

  * Running genksyms with --warnings breaks the kernel build; and the
    warning is output really often.

  * The described situation is easily reproducible with the given
    example, but it is not relevant:  Symbols for exported functions are
    hashed for their _source_ c module appearance; all users simply
    record the found hash to allow the loader to verify the recorded
    hash with the one provided by the function export.

  * The actual problem that has been described is probably related to
    some purely out-of-tree kmod organisation issues.

Nicolas


PS: Module symvers topic is probably better handled via
linux-modules@...r.kernel.org and linux-kbuild@...r.kernel.org

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)