netdev - Re: [regresssion 4.15] Userspace compilation broken by uapi/linux/if

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:   Fri, 26 Jan 2018 18:17:23 +0100
From:   Guillaume Nault <g.nault@...halink.fr>
To:     David Miller <davem@...emloft.net>,
        Hauke Mehrtens <hauke@...ke-m.de>
Cc:     netdev@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [regresssion 4.15] Userspace compilation broken by
 uapi/linux/if_ether.h update

On Fri, Jan 26, 2018 at 11:51:38AM +0100, Guillaume Nault wrote:
> On Thu, Jan 25, 2018 at 11:21:34PM +0100, Hauke Mehrtens wrote:
> > On 01/25/2018 03:58 PM, Guillaume Nault wrote:
> > > Now that linux/libc-compat.h is included in linux/if_ether.h, it is
> > > processed before netinet/in.h. Therefore, it sets the relevant
> > > __UAPI_DEF_* guards to 1 (as _NETINET_IN_H isn't yet defined).
> > > Then netinet/in.h is included, followed by linux/in.h. The later
> > > doesn't realise that what it defines has already been included by
> > > netinet/in.h because the __UAPI_DEF_* guards were set too early.
> > > 
> > This is about this commit:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6926e041a8920c8ec27e4e155efa760aa01551fd
> > 
> > On option would be to move this into include/uapi/linux/if_ether.h and
> > remove the include for libc-compat.h:
> > #ifndef __UAPI_DEF_ETHHDR
> > #define __UAPI_DEF_ETHHDR		1
> > #endif
> > 
> > This will only work if netinet/if_ether.h is included before
> > linux/if_ether.h, but I think this is very likely.
> >
> I don't see what makes its likely. That's not directly related to your
> point, but for example, glibc guarantees the opposite as it includes
> linux/if_ether.h at the beginning of netinet/if_ether.h.
> 
> > I think we can do this because we do not need some special libc handling
> > like it is done for other symbols as __UAPI_DEF_ETHHDR is currently only
> > needed by musl and not by glibc.
> > 
> That's ok for me as long as existing projects keep compiling. But all
> __UAPI_DEF_* are currently centralised in libc-compat.h. Adding
> __UAPI_DEF_ETHHDR in if_ether.h looks like defeating the purpose of
> libc-compat.h and I wonder if that'd be accepted. Maybe with a
> different name.
> 
> In any case, we're really late in the release cycle. If more discussion
> is needed, it's probably better to revert and take time to work on a
> solution for the next release.
> 
Hi David,

I just realise you've sent your last pull request for this release. I
was waiting for feedbacks in order to avoid a revert. Should I send a
revert now or do you prefer to sort this out later and backport a fix
in 4.15.1?