linux-kernel - Re: [PATCH v2 1/8] x86: vdso: Introduce asm/vdso/mman.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: <35f002ae-44bc-4887-a7e8-c00155b6cf7c@app.fastmail.com>
Date: Thu, 26 Sep 2024 06:20:08 +0000
From: "Arnd Bergmann" <arnd@...db.de>
To: "Christophe Leroy" <christophe.leroy@...roup.eu>,
 "Vincenzo Frascino" <vincenzo.frascino@....com>,
 linux-kernel@...r.kernel.org, Linux-Arch <linux-arch@...r.kernel.org>,
 linux-mm@...ck.org
Cc: "Andy Lutomirski" <luto@...nel.org>,
 "Thomas Gleixner" <tglx@...utronix.de>,
 "Jason A . Donenfeld" <Jason@...c4.com>,
 "Michael Ellerman" <mpe@...erman.id.au>,
 "Nicholas Piggin" <npiggin@...il.com>, "Naveen N Rao" <naveen@...nel.org>,
 "Ingo Molnar" <mingo@...hat.com>, "Borislav Petkov" <bp@...en8.de>,
 "Dave Hansen" <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>, "Theodore Ts'o" <tytso@....edu>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "Steven Rostedt" <rostedt@...dmis.org>,
 "Masami Hiramatsu" <mhiramat@...nel.org>,
 "Mathieu Desnoyers" <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH v2 1/8] x86: vdso: Introduce asm/vdso/mman.h

On Thu, Sep 26, 2024, at 05:51, Christophe Leroy wrote:
> Le 25/09/2024 à 23:23, Arnd Bergmann a écrit :
>> I agree that moving the contents out of uapi/ into vdso/ namespace
>> is not a solution here because that removes the contents from
>> the installed user headers, but we still need to do something
>> to solve the issue.
>
> Should header inclusion be reworked so that only UAPI and VDSO pathes 
> are looked for when including headers in VDSO builds ?

I think that could work. Not sure how hard it will be to
get to that point, but I like the idea.

>> The easiest workaround I see for this particular file is to
>> move the contents of arch/{arm,arm64,parisc,powerpc,sparc,x86}/\
>> include/asm/mman.h into a different file to ensure that the
>> only existing file is the uapi/ one. Unfortunately this does
>> not help to avoid it regressing again in the future.
>
> Could we add a check in checkpatch.pl to ensure UAPI headers do not 
> include headers that exist both in UAPI and non-UAPI space in the future ?

That is a much weaker check, I suspect it won't actually catch
most regressions as it's too easy to ignore checkpatch warnings.

     Arnd