linux-kernel - CONFIG_* symbols in UAPI headers?

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: <20190408124640.GA607@lst.de>
Date:   Mon, 8 Apr 2019 14:46:40 +0200
From:   Christoph Hellwig <hch@....de>
To:     Jie Zhang <jie.zhang@...log.com>
Cc:     Mike Frysinger <vapier@...too.org>,
        David Howells <dhowells@...hat.com>,
        Arnd Bergmann <arnd@...db.de>, linux-arch@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: CONFIG_* symbols in UAPI headers?

I just stumbled over the MAP_UNINITIALIZED defintion, initially
added by:

commit ea637639591def87a54cea811cbac796980cb30d
Author: Jie Zhang <jie.zhang@...log.com>
Date:   Mon Dec 14 18:00:02 2009 -0800

    nommu: fix malloc performance by adding uninitialized flag

The defintion depends on CONFIG_MMAP_ALLOW_UNINITIALIZED, which
will never be set by userspace.  How is this supposed to work?

Shoudn't we define the symbol unconditionally and just turn it
into a no-op in the implementation?

There are a few similar issues, like struct elf_prstatus having
a different layout depending on CONFIG_BINFMT_ELF_FDPIC, or
MAX_SHARED_LIBS defending on CONFIG_BINFMT_SHARED_FLAT.