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]
Message-ID: <21e624b9-7ab1-dcf9-fb1e-c31dd564a283@hauke-m.de>
Date:   Tue, 25 Apr 2017 08:45:43 +0200
From:   Hauke Mehrtens <hauke@...ke-m.de>
To:     musl@...ts.openwall.com, David Woodhouse <dwmw2@...radead.org>,
        Felix Janda <felix.janda@...teo.de>,
        linux-kernel@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>, linux-api@...r.kernel.org
Subject: Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to
 opt out of uapi definitions

On 03/08/2017 05:39 PM, Carlos O'Donell wrote:
> Any header needing compat with a libc includes libc-compat.h (per the 
> documented way the model works). With this patch any included linux kernel
> header that also includes libc-compat.h would immediately define all 
> the __UAPI_DEF_* constants to 1 as-if it had defined those structures, 
> but it has not.
> 
> For example, with these two patches applied, the inclusion of linux/if.h
> would define __UAPI_DEF_XATTR to 1, but linux/if.h has not defined
> XATTR_CREATE or other constants, so a subsequent inclusion sys/xattrs.h
> from userspace would _not_ define XATTR_CREATE because __UAPI_DEF_XATTR set
> to 1 indicates the kernel has.
> 
> I don't want to read into the model you are proposing and would rather you
> document the semantics clearly so we can all see what you mean.

What about moving the code from libc-comapt.h into the specific header
files? This way including linux/if.h would not have an impact on
__UAPI_DEF_XATTR, because this is defined in linux/xattr.h. We would
still have a problem when the specific Linux header file gets included
before the libc header file, but at least musl does not support this anyway.

Hauke

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ