linux-kernel - Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and _

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: <16ec5b22-a3c1-1bf4-edc3-e1b2342be7f0@vodafone.de>
Date:   Sun, 21 Aug 2016 11:03:21 +0200
From:   Christian König <deathsimple@...afone.de>
To:     Mikko Rapeli <mikko.rapeli@....fi>,
        Emil Velikov <emil.l.velikov@...il.com>
Cc:     Marek Olšák <maraeo@...il.com>,
        ML dri-devel <dri-devel@...ts.freedesktop.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and
 __u64 from <linux/types.h>"

Am 20.08.2016 um 19:58 schrieb Mikko Rapeli:
> Cc'ing lkml too.
>
> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
>> Story time:
>> I was dreaming of a day were we can stop installing these headers,
>> thus making deprecation a bit easier process.
>> Yet after failing to convince Dave and Daniel on a number of occasions
>> I've accepted that those headers _are_ here to stay. And yes they
>> _are_ the UAPI, even though no applications are meant to use them but
>> the libdrm 'version'.
>> Thus any changes to the libdrm ones should be a mirror of the ones
>> here and libdrm should _not_ differ.
> Another day dream:
>
> Wouldn't it be nice if the uapi headers from Linux kernel would pass
> a simple quality check of compiling in userspace where they are meant to be
> used?

libdrm has a whole bunch of unit tests exercising the kernel UAPI 
headers for both API and ABI compatibility.

So to be honest I see your good intentions here, but no those checks are 
completely useless for us.

Christian.

>   Stand alone. Without magic tricks and additional libraries and their
> headers. Without glibc or any other libc implementation specific additions.
> The uapi headers define many parts of the Linux kernel API and ABI, and thus
> compiling them also without the 'official' GNU/Linux userspace libraries
> like glibc or libdrm does have some uses. For example API and ABI
> compatibility checks and API/ABI/system call fuzzers.
>
> Many headers required stdint.h types but Linux kernel headers do not
> define them in userspace, and then Linus has said that uapi headers
> should use the linux/types.h with double underscores. Thus my patches
> for fixing trivial compile errors turned into changing several stdint.h
> definitions to linux/types.h.
>
> Yes, there have been some regressions in this work but to err is human.
> What is the actual problem and how can we (yes, including me) try to
> solve it?
>
> -Mikko