linux-kernel - Re: [PATCH v3 1/6] selftests/mm: mseal, self_elf: fix missing __NR

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: Tue, 18 Jun 2024 13:14:05 -0700
From: John Hubbard <jhubbard@...dia.com>
To: David Hildenbrand <david@...hat.com>, Andrew Morton
	<akpm@...ux-foundation.org>, Jeff Xu <jeffxu@...omium.org>, Shuah Khan
	<shuah@...nel.org>
CC: Andrei Vagin <avagin@...gle.com>, Axel Rasmussen
	<axelrasmussen@...gle.com>, Christian Brauner <brauner@...nel.org>, Kees Cook
	<kees@...nel.org>, Kent Overstreet <kent.overstreet@...ux.dev>, "Liam R .
 Howlett" <Liam.Howlett@...cle.com>, Muhammad Usama Anjum
	<usama.anjum@...labora.com>, Peter Xu <peterx@...hat.com>, Rich Felker
	<dalias@...c.org>, <linux-mm@...ck.org>, <linux-kselftest@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/6] selftests/mm: mseal, self_elf: fix missing
 __NR_mseal

On 6/17/24 11:56 PM, David Hildenbrand wrote:
> On 18.06.24 04:24, John Hubbard wrote:
...
>> diff --git a/tools/testing/selftests/mm/seal_elf.c b/tools/testing/selftests/mm/seal_elf.c
>> index f2babec79bb6..27bf2f84231d 100644
>> --- a/tools/testing/selftests/mm/seal_elf.c
>> +++ b/tools/testing/selftests/mm/seal_elf.c
>> @@ -2,7 +2,7 @@
>>   #define _GNU_SOURCE
>>   #include <sys/mman.h>
>>   #include <stdint.h>
>> -#include <unistd.h>
>> +#include <asm-generic/unistd.h>
>>   #include <string.h>
>>   #include <sys/time.h>
>>   #include <sys/resource.h>
> 
> Still confused. Let's take a look at "microblaze".
> 
> arch/microblaze/include/asm/unistd.h
>   -> #include <uapi/asm/unistd.h>
> 
> arch/microblaze/include/uapi/asm/unistd.h
>   -> #include <asm/unistd_32.h>
>    -> Generated during "make headers"
> 
> usr/include/asm/unistd_32.h is generated via
> arch/microblaze/kernel/syscalls/Makefile with the syshdr command.
> 
> So we never end up including asm-generic/unistd.h directly on microblaze, but rather converts it (IIUC) to something else.
>

Yes.
  
> That will work as expected here?
> 

No. :)

The problem, and the source of confusion here, is that for most user
space programs, the header file inclusion behaves as you've mentioned
above. However, those programs are installed on a single computer that
has a single set of asm and kernel headers installed.

We are quite special here, because we are building a set of user space
programs that:

     a) Mostly avoids using the installed (distro) system header files.

     b) Must build (and run) on all supported CPU architectures

     c) Must occasionally use symbols that have so new that they have not
        yet been included in the distro's header files.

Doing (a) creates a new problem: how to get a set of cross-platform
headers that works in all cases.

Fortunately, asm-generic headers solve that one. Which is why we need to
use them here.

The reason this hasn't really come up yet, is that until now, the
kselftests requirement (which I'm trying to remove) was that "make
headers" must first be run. That allowed the selftests to get a snapshot
of sufficiently new header files that looked just like (and conflict
with) the installed system headers.

I can update the commit description with some of the above, if it helps.

thanks,
-- 
John Hubbard
NVIDIA