linux-kernel - genksyms: separating public headers from private header files

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

Message-ID: <20140716151915.GS7959@redhat.com>
Date:	Wed, 16 Jul 2014 11:19:15 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	JBeulich@...e.com, mmarek@...e.cz
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: genksyms: separating public headers from private header files

Hi Jan, Michal,

I am not sure who maintains genksyms officially, so I am sending this
question to the two of you as folks who seemed to have contributed to the
tool. :-)

I noticed with genksyms that a symbol is opaquely defined in a
public header file (on purpose) and then fully defined in a private
header.  This is normal practice.  Further, symbol checksumming is done on
EXPORT_SYMBOLs in a private c file that includes the private header
files.

As a result, even though a struct symbol is intentionally opaquely defined
in a public header file consumed by a third party module, the symbol
checksumming still includes the full definition (because the private c
file with the actual export symbol has the full definition).  This has
made it difficult to modify the private header file struct because it
breaks the symbol checksumming.

For example, let's consider

block/blk-core.c:EXPORT_SYMBOL(blk_put_queue);

blk_put_queue will eventually depend on struct blkcq_gq.

Now publicly blkcg_gq is defined opaquely in 

include/linux/blkdev.h

and privately in

block/block-cgroup.h

Now when we checksum blk_put_queue both include/linux/blkdev.h and
block/block-cgroup.h are included in block/blk-core.c, so blkcg_gq is
fully defined for checksumming.

Later if we modify blkcq_gq in block/block-cgroup.h the checksum changes,
even though it can debated that block-cgroup.h is a private header file
and it should not impact kabi for third party modules.

Have either of you run into this?  Or is the argument that private files
should not impact the checksum not as strong as I might think?  Or is it a
technical problem of how to separate the public includes from the private
includes in the preprocessed file?

Thanks!

Cheers,
Don

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/