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: <20170131054124.GA21189@ravnborg.org>
Date:   Tue, 31 Jan 2017 06:41:24 +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

On Mon, Jan 30, 2017 at 08:58:33AM +0100, Ingo Molnar wrote:
> 
> * Sam Ravnborg <sam@...nborg.org> wrote:
> 
> > On Sat, Jan 28, 2017 at 11:11:22PM +0100, Ingo Molnar wrote:
> > > 
> > > The plan is to keep the old UAPI header in place but the kernel won't
> > > use it anymore - and after some time we'll try to remove it. (User-space
> > > tools better have local copies of headers anyway, instead of relying
> > > on kernel headers.)
> > 
> > The idea with uapi is the the kernel provides a sane set of headers
> > to be used by user space.
> > So we avoid random copies that is maintained by random people in random
> > ways resulting in random bugs.
> 
> Your argument is simplistic which presents a false dichotomy: maintaining a copy 
> or fully sharing the header are not the only two options available to share the 
> information in the headers between the kernel and tooling: for example perf uses a 
> half-automated method where headers are copied from the kernel, but also checked 
> automatically against the upstream kernel, and a (non-fatal) warning is emitted 
> during the build if the upstream header has changed.

Obvious when there are two vastly different solutions there are some
middle ground solutions too.
And perf implements a tool based method to check that the manually
copied/created/maintained headers are in sync with the kernel.
which is just another way to maintain a set of copied headers.

But this does not at all address the point which is that it is
an unessesary burden to put on all the _users_ of the kernel uapi
headers to amintain their own copy of the kernel headers
(tool assisted or not).

The rationale behind requesting the users of the kernel uapi headers
seems to be that the kernel people would like to have the freedom
to fix wrong doings in the past without violatign the uapi.
So the benefit here is simpler headers on the kernel side compared
to all users of kernel uapi heders to manually (tool assisted or not)
maintaining their own copies of the uapi kernel headers.

Heck - if this is how it should be done then the the kernel
should provide the copy of the headers that describe the
uapi and the kernel should have the tool infrastructure to check
that the headers are OK.
Not all the users outside the kernelspace.

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.

	Sam