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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 16 Mar 2017 10:26:44 +0200
From:   Mikko Rapeli <mikko.rapeli@....fi>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Hauke Mehrtens <hauke@...ke-m.de>, davem@...emloft.net,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        jarod@...hat.com, jogo@...nwrt.org, david.heidelberger@...t.cz,
        maillist-linux@...fooze.de
Subject: Re: [PATCH 3/4] uapi glibc compat: Do not check for __USE_MISC

On Thu, Mar 16, 2017 at 07:59:12AM +0000, David Woodhouse wrote:
> On Sun, 2017-03-12 at 23:00 +0100, Hauke Mehrtens wrote:
> > __USE_MISC is glibc specific and not available in musl libc. Only do
> > this check when glibc is used. This fixes a problem with musl libc.
> > ...
> > -/* Coordinate with glibc net/if.h header. */
> > -#if defined(_NET_IF_H) && defined(__USE_MISC)
> > +/* Coordinate with libc net/if.h header. */
> > +#if defined(_NET_IF_H) && (!defined(__GLIBC__) || defined(__USE_MISC))
> 
> I *really* don't like building up a plethora of knowledge about
> specific libc implementations in the kernel. As a general rule, if we
> have *anything* that depends on __GLIBC__ then we are Doing It Wrong™.

Kernel does not depend on glibc but uapi headers check for some defintions
so that userspace code can include both libc and kernel header files
without compiler errors.

This interface between kernel and libc header files is messy due to long
history of copying header files from kernel to libc implementations etc
and thus this kind of ifdef magic with in depth knowledge of various
libc's defintions is currently unavoidable.

-Mikko

Powered by blists - more mailing lists