[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABi2SkUih8XrA4aJwngAoByCytg-PthJ8JrkKpzJRFP=f9zyKA@mail.gmail.com>
Date: Tue, 10 Sep 2024 07:15:18 -0700
From: Jeff Xu <jeffxu@...omium.org>
To: Muhammad Usama Anjum <Usama.Anjum@...labora.com>
Cc: 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
Hi Muhammad
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
> >> 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().
>
We shouldn't use glibc to test mseal, mseal is a security feature, and
an attacker can access syscall directly, so the test needs to test
with as little layer as possible.
I think there are two options:
1> switch everything to use __NR_mmap2
2> switch to __NR_mmap2 only for ARM.
I'm not sure which one is more appropriate though.
Thanks
-Jeff
> --
> BR,
> Muhammad Usama Anjum
>
Powered by blists - more mailing lists