linux-kernel - Re: [PATCH 01/50] x86/boot/e820: Introduce arch/x86/include/asm/e820/types.h

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: <20170131172259.GA22807@ravnborg.org>
Date:   Tue, 31 Jan 2017 18:22:59 +0100
From:   Sam Ravnborg <sam@...nborg.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Lutomirski <luto@...capital.net>,
        Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Yinghai Lu <yinghai@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...radead.org>
Subject: Re: [PATCH 01/50] x86/boot/e820: Introduce
 arch/x86/include/asm/e820/types.h

> > 
> > So just to repeat - it is an error prone design to let users
> > of the kernel uapi maintain their own copies of the kernel
> > uapi header. It is the job of the kernel.
> 
> But "random copies" is not what perf does. Tell me, how is the perf mechanism of 
> using the headers "error-prone"? It's a delayed COW mechanism - COW is not an 
> error-prone concept in any way ...

The whole concept that user space have the burden to maintain
a set of headers describing the uapi provided by the kernel is the point
of discussion.

The randomness come into play when a user space developer are
faced with the challenge that the programm require access to something
described by the kernel uapi and then have to hunt for a header
that describes said uapi.

In this thread we have covered one rational reason to push thus
burden to user space - to give the kernel the freedom to repair
past stupidity (being that in naming or some other sort).

So lets turn around the arguments - and from a user space
perspective what is the benefit of maintaining a set of headers
describing the kernel uapi?

Obviously this allows user space to name thing exactly the
way they like, and allows user space to put all sorts of strange
things in the header files describing the kernel uapi.

This is just not enough good reasons why the user space
developer shall create headers files describing
the kerneluapi and maintain tooling to maintain the header
files describing the kernel uapi.

Are there other benefits that is missed which makes the
concept of letting user space maintain header files describing
the kernel uapi a good idea that is missed?

	Sam