linux-kernel - Re: [PATCH] selftests: Fix memfd to support relocatable build (O=objdir)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3fa8af77-4b4b-c1e2-2467-fb7b9adb3f66@linuxfoundation.org>
Date:   Thu, 26 Mar 2020 16:33:45 -0600
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     "Bird, Tim" <Tim.Bird@...y.com>,
        "shuah@...nel.org" <shuah@...nel.org>
Cc:     "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH] selftests: Fix memfd to support relocatable build
 (O=objdir)

On 3/26/20 4:23 PM, Bird, Tim wrote:
>> -----Original Message-----
>> From: Shuah Khan
>>
>> Fix memfd to support relocatable build (O=objdir). This calls out
>> source files necessary to build tests and simplfies the dependency
>> enforcement.
>>
>> Tested the following:
>>
>> Note that cross-build for fuse_mnt has dependency on -lfuse.
>>
>> make all
>> make clean
>> make kselftest-install O=/arm64_build/ ARCH=arm64 HOSTCC=gcc \
>> CROSS_COMPILE=aarch64-linux-gnu- TARGETS=memfd
>>
>> Signed-off-by: Shuah Khan <skhan@...uxfoundation.org>
>> ---
>>   tools/testing/selftests/memfd/Makefile | 9 ++++-----
>>   1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/testing/selftests/memfd/Makefile b/tools/testing/selftests/memfd/Makefile
>> index 53a848109f7b..0a15f9e23431 100644
>> --- a/tools/testing/selftests/memfd/Makefile
>> +++ b/tools/testing/selftests/memfd/Makefile
>> @@ -4,9 +4,8 @@ CFLAGS += -I../../../../include/uapi/
>>   CFLAGS += -I../../../../include/
>>   CFLAGS += -I../../../../usr/include/
>>
>> -TEST_GEN_PROGS := memfd_test
>> +TEST_GEN_PROGS := memfd_test fuse_test fuse_mnt
>>   TEST_PROGS := run_fuse_test.sh run_hugetlbfs_test.sh
>> -TEST_GEN_FILES := fuse_mnt fuse_test
>>
>>   fuse_mnt.o: CFLAGS += $(shell pkg-config fuse --cflags)
>>
>> @@ -14,7 +13,7 @@ include ../lib.mk
>>
>>   $(OUTPUT)/fuse_mnt: LDLIBS += $(shell pkg-config fuse --libs)
> 
> Sorry to interject here.  This comment doesn't have to do with this patch,
> but the above line is problematical for cross-compilation.
> $(shell pkg-config fuse --libs) will use pkg-config from the host
> machine, and may produce something different from what's
> installed on the target.  For most enterprise and desktop systems
> library paths for are mostly standardized.  The effect is that if
> you're doing 'simple' embedded, the pkg-config output on the
> host will match that of the target board.  However, in some
> embedded products the partition and filesystem setups are
> often quite complicated (e.g. I recently worked on a TV set with 14
> partitions) and things are not in the locations preferred by the
> Filesystem Hierarchy Standard.
> 
> When cross-compiling for our products, we tend to use the pkg-config
> from the filesystem of the target (a copy of which is on the host), rather
> than the host's pkg-config.
> 
Thanks for bringing attention to the issue. This is an existing
issue. Thankfully this is one of the two tests that use pkg-config.

The problem is limited to just two tests that are included in the
Makefile TARGETS.

> I don't have a board in my test lab where this shows up, nor a
> proposed solution at the moment, but I'm just mentioning it as a
> potential host-environment build contamination issue.  Maybe I
> should start keeping a list, and start thinking of possible solutions for
> more of these types of issues.


Thanks for bringing attention to the issue. I will keep an eye out for
this kind of usage during my reviews.

> 
> P.S. I'd ignore this issue for approving this patch.  I'm just bringing
> it up as a red flag for future work.

Thanks. This is an existing problem that can be addressed in a separate
page.

thanks,
-- Shuah