linux-kernel - Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

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:   Mon, 23 Jan 2017 23:24:02 +0100 (CET)
From:   Jan Engelhardt <jengelh@...i.de>
To:     Borislav Petkov <bp@...en8.de>
cc:     Christoph Hellwig <hch@...radead.org>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>, arnd@...db.de,
        mmarek@...e.com, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        airlied@...ux.ie, davem@...emloft.net, linux@...linux.org.uk,
        slash.tmp@...e.fr, daniel.vetter@...ll.ch,
        rmk+kernel@...linux.org.uk, msalter@...hat.com,
        tklauser@...tanz.ch, mpe@...erman.id.au, mingo@...nel.org,
        hpa@...or.com
Subject: Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

On Monday 2017-01-23 18:26, Borislav Petkov wrote:

>On Mon, Jan 23, 2017 at 09:21:03AM -0800, Christoph Hellwig wrote:
>> Or keep the exported version as-is and never changed it, and use
>> a different copy for the kernel itself.
>
>I guess we'll have to do that if something in userspace has put its
>sticky fingers on that file and cannot be fixed. Which I hardly doubt
>but we can't break that damn userspace.

The importance of uapi headers presence is a bit overrated.

If you look at, for example, iptables (and further projects in that 
area), copies of uapi headers have been made (and this process is likely 
to continue) because it could be compiled on a variety of vintage 
systems that do not have all required #defines yet.

Similarly, it may be built on a variety of _modern_ systems whose 
kernels no longer have a particular thing (e.g. ipt_SAME), so it also 
ships copies of those headers.

So if some userspace component depends on that particular msr header (which,
unlike ipt_SAME, was not intended for export), is it not reasonable to expect
them to make a copy if and when they need it?