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: Wed, 12 Jun 2024 19:11:35 -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 0/5] cleanups, fixes, and progress towards avoiding "make
 headers"

On 6/12/24 1:24 AM, David Hildenbrand wrote:
> On 11.06.24 22:54, John Hubbard wrote:
>> On 6/11/24 2:36 AM, David Hildenbrand wrote:
>>> On 08.06.24 04:10, John Hubbard wrote:
>>>> Eventually, once the build succeeds on a sufficiently old distro, the
>>>> idea is to delete $(KHDR_INCLUDES) from the selftests/mm build, and then
>>>> after that, from selftests/lib.mk and all of the other selftest builds.
>>>>
>>>> For now, this series merely achieves a clean build of selftests/mm on a
>>>> not-so-old distro: Ubuntu 23.04:
>>>
>>> Wasn't the plan to rely on the tools/include headers, and pull in there whatever we need?
>>
>> Yes, it is. You are correct.
>>
>>>
>>>>
>>>> 1. Add __NR_mseal.
>>>>
>>>
>>> For example, making sure that tools/include/uapi/asm-generic/unistd.h is updated to contain __NR_mseal?
>>
>> Well, here it gets less clear cut, because the selftests pull in *lots* of
>> system headers. In this case /usr/include/unistd.h gets pulled in. If we
>> force tools/include/uapi/asm-generic/unistd.h to be included, then we'll
>> get many many warnings of redefinitions of __NR_* items.
> 
> I think, there is a difference between unistd.h and linux/unistd.h. We want to continue including unistd.h from the distro, but might want to stop including the linux one from the distro.
> 
> My thinking was that we start maintaining our own linux headers copy in-tree, and start converting our tests from including <linux/> supplied by the distro to include the in-tree ones.
> 
> For mseal_test.c, that might mean stopping including "linux/mman.h", and instead including the in-tree one.

Yes. Something like that.

$ find /usr -name 'unistd*.h'  | wc -l
14
$ find /kernel_work/linux-github/ -name 'unistd*.h'  | wc -l
54

heh. :)

> 
>>
>> So what's really going on here is that we have this uneasy mix of system
>> headers from the test machine, and newer versions of some of those headers
>> in the kernel tree. And some of those are easier to combine with system
>> headers, than others. unistd.h is clearly not going quietly, which is
>> why, I believe, the "#ifndef __NR_* " approach has flowered in the
>> selftests.
> 
> Right, these mixtures are not what we want I think. But I have no idea how easy it would be to convert individual tests.
> 
> Maybe all it takes is updating the in-tree headers and then including "TBD/linux/whatever.h" instead of <linux/whatever.h>
> 
> In QEMU, we maintain some (not all) kernel headers ourselves, and include them via
> 
> "standard-headers/linux/whatever.h"

Let me look into it. Maybe it's fairly simple, we shall see.

> 
>>
>>>
>>> ... to avoid hand-crafted defines we have to maintain for selftests.
>>>
>>> But maybe I am remembering something outdated.
>>>
>>
>> You remembered correctly, but the situation is slighly muddier than
>> one would prefer. :)
> 
> 
> Absolutely, and I appreciate that you are trying to improve the situation.
> 

I think the attempts to further tease apart the include headers could
go into a separate, subsequent series, yes? And let this one go in
unmolested for now?


thanks,
-- 
John Hubbard
NVIDIA


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ