Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 836735 - app-misc/pax-utils: seccomp filter kills scanelf when glibc hugetlb tunable set (madvise)
Summary: app-misc/pax-utils: seccomp filter kills scanelf when glibc hugetlb tunable s...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: glibc-2.35
  Show dependency tree
 
Reported: 2022-04-04 05:39 UTC by Reuben Martin
Modified: 2022-04-25 01:52 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Reuben Martin 2022-04-04 05:39:04 UTC
I stumbled across a very odd bug that doesn't make much sense to me. I am trying out a new tunable available in glibc-2.35 where I set glibc.malloc.hugetlb=1

https://www.gnu.org/software/libc/manual/html_node/Memory-Allocation-Tunables.html#index-glibc_002emalloc_002ehugetlb

With this tunable setting, scanelf, as called by portage, always results in an "unknown syscall" for seccomp. This is way over my head. I have no idea why glibc utilizing hugetlb would have any such effect on a the seccomp syscall.

Reproducible: Always
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-04-04 06:04:04 UTC
If you try using scanelf by yourself on some binary, does it die?

Could you strace it to find out which?
Comment 2 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-04-04 06:05:29 UTC
(In reply to Sam James from comment #1)
> If you try using scanelf by yourself on some binary, does it die?
> 
> Could you strace it to find out which?

Eh, reproduced.

> # GLIBC_TUNABLES=glibc.malloc.hugetlb=1 scanelf
>Bad system call (core dumped)

>openat(AT_FDCWD, "/sys/kernel/mm/transparent_hugepage/hpage_pmd_size", O_RDONLY) = 3
>read(3, "2097152\n", 21)                = 8
>close(3)                                = 0
>brk(NULL)                               = 0x5615e690f000
>brk(0x5615e6b0f000)                     = 0x5615e6b0f000
>madvise(0x5615e690f000, 2097152, MADV_HUGEPAGE) = 28
>+++ killed by SIGSYS (core dumped) +++
>Bad system call (core dumped)
Comment 3 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-04-04 06:07:48 UTC
glibc is using madvise to record that huge pages are being used. I think madvise is pretty reasonable for us to call.

In fact, we've considered adding it to scanelf itself in bug 749624.
Comment 4 Larry the Git Cow gentoo-dev 2022-04-25 01:20:52 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/proj/pax-utils.git/commit/?id=d9f65269d7182ef1d313e3b87bcea37e45958561

commit d9f65269d7182ef1d313e3b87bcea37e45958561
Author:     WANG Xuerui <xen0n@gentoo.org>
AuthorDate: 2022-04-24 18:41:55 +0000
Commit:     WANG Xuerui <xen0n@gentoo.org>
CommitDate: 2022-04-25 01:19:39 +0000

    seccomp: allow madvise() call (glibc 2.35+)
    
    Closes: https://bugs.gentoo.org/836735
    Reviewed-by: Sam James <sam@gentoo.org>
    Signed-off-by: WANG Xuerui <xen0n@gentoo.org>

 seccomp-bpf.c |  3 +++
 seccomp-bpf.h | 76 +++++++++++++++++++++++++++++------------------------------
 2 files changed, 41 insertions(+), 38 deletions(-)