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: <20200603114546.GA125404@port70.net>
Date:   Wed, 3 Jun 2020 13:45:46 +0200
From:   Szabolcs Nagy <nsz@...t70.net>
To:     Rich Felker <dalias@...c.org>
Cc:     musl@...ts.openwall.com, libc-alpha@...rceware.org,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: sys/sysinfo.h clash with linux/kernel.h


i think the linux-api list is the right place for this
so adding it on cc.

* Rich Felker <dalias@...c.org> [2020-06-02 17:37:05 -0400]:
> linux/kernel.h is a uapi header that does almost nothing but define
> some internal-use alignment macros and -- oddly -- include
> linux/sysinfo.h to provide a definition of struct sysinfo. It's
> included only from 6 places in the kernel uapi headers:
> 
> include/uapi/linux/lightnvm.h
> include/uapi/linux/ethtool.h
> include/uapi/linux/sysctl.h
> include/uapi/linux/netlink.h
> include/uapi/linux/netfilter/x_tables.h
> include/uapi/linux/mroute6.h
> 
> However, it's also included from glibc's sys/sysinfo.h to provide
> struct sysinfo (glibc depends on the kernel for the definition). On
> musl, this produces a conflicting definition if both sys/sysinfo.h and
> any of the above 6 headers are included in the same file.
> 
> I think the underlying problem here is that the same header is used
> for two very disjoint purposes: by glibc as the provider of struct
> sysinfo, and by other kernel headers as provider of the alignment
> macros.
> 
> The glibc use is effectively a permanent contract that can't be
> changed, so what I'd like to do is move the macros out to a separate
> header (maybe linux/something_macros.h?) and have linux/kernel.h and
> the above 6 uapi headers all include that. Then nothing but
> linux/kernel.h would pull in linux/sysinfo.h.

i think providing a patch would make this happen faster.

ideally uapi would be reorganized such that it's clear
what headers are supposed to be compatible with inclusion
together with libc headers and what headers may conflict.

> 
> Note that in practice this is a rather hard issue to hit since almost
> nothing needs sysinfo() at the same time as the above uapi interfaces.
> However it did come up in toybox, which is how I first (just today)
> learned about the conflict, so it seems like something that should be
> fixed.
> 
> Rich

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ