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] [day] [month] [year] [list]

Message-ID: <f9b6ae72-5f72-4569-b083-ab62e5d91382@arm.com>
Date: Fri, 27 Sep 2024 14:09:04 +0100
From: Vincenzo Frascino <vincenzo.frascino@....com>
To: Arnd Bergmann <arnd@...db.de>,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 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 25/09/2024 22:23, Arnd Bergmann wrote:
> On Wed, Sep 25, 2024, at 06:51, Christophe Leroy wrote:
>> Le 23/09/2024 à 16:19, Vincenzo Frascino a écrit :
>>> @@ -0,0 +1,15 @@
...

>>
>> I still can't see the point with that change.
>>
>> Today 4 architectures implement getrandom and none of them require that 
>> indirection. Please leave prot and flags as they are in the code.
>>
>> Then this file is totally pointless, VDSO code can include 
>> uapi/linux/mman.h directly.
>>
>> VDSO is userland code, it should be safe to include any UAPI file there.
> 
> I think we are hitting an unfortunate corner case in the build
> system here, based on the way we handle the uapi/ file namespace
> in the kernel:
> 
> include/uapi/linux/mman.h includes three headers: asm/mman.h,
> asm-generic/hugetlb_encode.h and linux/types.h. Two of these
> exist in both include/uapi/ and include/, so while building
> kernel code we end up picking up the non-uapi version which
> on some architectures includes many other headers.
> 
> 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.
>
> 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.
> 
> To go a little step further I would also move
> uapi/asm-generic/hugetlb_encode.h to uapi/linux/hugetlb_encode.h
> or merge it into uapi/linux/mman.h. This file has no business
> in asm-generic/* since there is only one copy.
> 
> After looking at this file for way too long, I somehow
> ended up with a (completely unrelated) cleanup series that
> I now posted at
> https://lore.kernel.org/lkml/20240925210615.2572360-1-arnd@kernel.org/T/#t
>

I had a look at your proposal and it seems definitely better then mine. Thanks
Arnd. I am happy to drop my changes and re-post only a small series with
PAGE_SIZE/MASK required rework.

>      Arnd

-- 
Regards,
Vincenzo