linux-kernel - Re: [PATCH] selftests: mm: Fix build errors on armhf

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: <406c2919-a546-40e4-89af-baa910c22740@collabora.com>
Date: Mon, 16 Sep 2024 10:11:18 +0500
From: Muhammad Usama Anjum <Usama.Anjum@...labora.com>
To: Jeff Xu <jeffxu@...omium.org>
Cc: Usama.Anjum@...labora.com, Andrew Morton <akpm@...ux-foundation.org>,
 Shuah Khan <shuah@...nel.org>, Kees Cook <kees@...nel.org>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>, kernel@...labora.com,
 stable@...r.kernel.org, linux-mm@...ck.org, linux-kselftest@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selftests: mm: Fix build errors on armhf

On 9/14/24 3:33 AM, Jeff Xu wrote:
> On Mon, Aug 19, 2024 at 3:05 AM Muhammad Usama Anjum
> <Usama.Anjum@...labora.com> wrote:
>>
>> On 8/14/24 3:29 AM, Jeff Xu wrote:
>>> Hi Muhammad
>>>
>>> On Fri, Aug 9, 2024 at 1:25 AM Muhammad Usama Anjum
>>> <usama.anjum@...labora.com> wrote:
>>>>
>>>> The __NR_mmap isn't found on armhf. The mmap() is commonly available
> 
> What is armhf ?
> is that arm64 ? I was able to build arm64 correctly.
It is arm architecture. Use following toolchain with it:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

Please test your patches on it.

> 
> -Jeff
> 
>>>> system call and its wrapper is presnet on all architectures. So it
>>>> should be used directly. It solves problem for armhf and doesn't create
>>>> problem for architectures as well. Remove sys_mmap() functions as they
>>>> aren't doing anything else other than calling mmap(). There is no need
>>>> to set errno = 0 manually as glibc always resets it.
>>>>
>>> The mseal_test should't have dependency on libc, and mmap() is
>>> implemented by glibc, right ?
>>>
>>> I just fixed a bug to switch mremap() to sys_mremap to address an
>>> issue that different glibc version's behavior is slightly different
>>> for mremap().
>>>
>>> What is the reason that __NR_mmap not available in armhf ? (maybe it
>>> is another name ?)  there must be a way to call syscall directly on
>>> armhf, can we use that instead ?
>>
>> It seems __NR_mmap syscall is deprecated for arm. Found this comment in
>> arch/arm/include/asm/unistd.h:
>> /*
>>  * The following syscalls are obsolete and no longer available for EABI:
>>  *  __NR_time
>>  *  __NR_umount
>>  *  __NR_stime
>>  *  __NR_alarm
>>  *  __NR_utime
>>  *  __NR_getrlimit
>>  *  __NR_select
>>  *  __NR_readdir
>>  *  __NR_mmap
>>  *  __NR_socketcall
>>  *  __NR_syscall
>>  *  __NR_ipc
>>  */
>>
>> The glibc mmap() calls mmap2() these days by adjusting the parameters
>> internally. From man mmap:
>> C library/kernel differences:
>> This  page  describes the interface provided by the glibc mmap() wrapper
>> function.  Originally, this function invoked a system call of the same
>> name.  Since Linux 2.4, that system call has been superseded  by
>> mmap2(2), and nowadays the glibc mmap() wrapper function invokes
>> mmap2(2) with a suitably adjusted value for offset.
>>
>> I'm not sure if behaviour of glibc mmap() and syscall mmap2() would be
>> same, but we should use glibc at most places which accounts for
>> different architectures correctly. Maybe the differences were only
>> present in case of mremap().
>>
>> --
>> BR,
>> Muhammad Usama Anjum
>>

-- 
BR,
Muhammad Usama Anjum