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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1b36ba43-60a4-441c-981f-9b62f366aa95@collabora.com>
Date: Mon, 19 Aug 2024 15:05:07 +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 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
>> 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