linux-kernel - Re: [PATCH 1/2] selftests/openat2: fix clang build failures: -static-libasan, LOCAL

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, 7 May 2024 09:19:38 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Ryan Roberts <ryan.roberts@....com>, Shuah Khan <shuah@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>,
 Christian Brauner <brauner@...nel.org>,
 Muhammad Usama Anjum <usama.anjum@...labora.com>,
 Alexey Gladkov <legion@...nel.org>, Valentin Obst <kernel@...entinobst.de>,
 linux-kselftest@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
 llvm@...ts.linux.dev
Subject: Re: [PATCH 1/2] selftests/openat2: fix clang build failures:
 -static-libasan, LOCAL_HDRS

On 5/7/24 12:45 AM, Ryan Roberts wrote:
> On 04/05/2024 05:43, John Hubbard wrote:
..
> Hi John,
> 
> I sent out a similar fix a couple of weeks ago, see [1]. I don't think it got
> picked up though. It takes a slightly different approach, explicitly adding
> -static-libsan (note no 'a') for clang, instead of relying on its default.
> 
> And it just drops helpers.h from the makefile altogether, on the assumption that
> it was a mistake; its just a header and shouldn't be compiled directly. I'm not
> exactly sure what the benefit of adding it to LOCAL_HDRS is?

Ah no, you must not drop headers.h. That's a mistake itself, because
LOCAL_HDRS adds a Make dependency; that's its purpose. If you touch
helpers.h it should cause a rebuild, which won't happen if you remove it
from LOCAL_HDRS.

The way it works is that lib.mk adds $(LOCAL_HDRS) to the dependencies list,
but then filters precisely that same set *out* of the list that it provides
to the compile invocation.

The other way to implement this requirement of "some things need to be
Make dependencies, and some need to be both dependencies and compilation
inputs", is to add everything to the dependency list, but then use a
separate list of files to pass to the compiler. For an example of that,
see $(EXTRA_FILES) in patch 1/7 [1] of my selftests/x86 cleanup.

[1] https://lore.kernel.org/all/20240503030214.86681-2-jhubbard@nvidia.com/

thanks,
John Hubbard

> 
> [1]
> https://lore.kernel.org/linux-kselftest/20240417160740.2019530-1-ryan.roberts@arm.com/
> 
> Thanks,
> Ryan
> 
> 
>> ---
>>   tools/testing/selftests/openat2/Makefile | 14 ++++++++++++--
>>   1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/testing/selftests/openat2/Makefile b/tools/testing/selftests/openat2/Makefile
>> index 254d676a2689..185dc76ebb5f 100644
>> --- a/tools/testing/selftests/openat2/Makefile
>> +++ b/tools/testing/selftests/openat2/Makefile
>> @@ -1,8 +1,18 @@
>>   # SPDX-License-Identifier: GPL-2.0-or-later
>>   
>> -CFLAGS += -Wall -O2 -g -fsanitize=address -fsanitize=undefined -static-libasan
>> +CFLAGS += -Wall -O2 -g -fsanitize=address -fsanitize=undefined
>>   TEST_GEN_PROGS := openat2_test resolve_test rename_attack_test
>>   
>> +# gcc requires -static-libasan in order to ensure that Address Sanitizer's
>> +# library is the first one loaded. However, clang already statically links the
>> +# Address Sanitizer if -fsanitize is specified. Therefore, simply omit
>> +# -static-libasan for clang builds.
>> +ifeq ($(LLVM),)
>> +    CFLAGS += -static-libasan
>> +endif
>> +
>> +LOCAL_HDRS += helpers.h
>> +
>>   include ../lib.mk
>>   
>> -$(TEST_GEN_PROGS): helpers.c helpers.h
>> +$(TEST_GEN_PROGS): helpers.c
>>
>> base-commit: ddb4c3f25b7b95df3d6932db0b379d768a6ebdf7
>> prerequisite-patch-id: b901ece2a5b78503e2fb5480f20e304d36a0ea27
> 

thanks,
-- 
John Hubbard
NVIDIA