[Bug dynamic-link/26831] aarch64: seccomp filters may prevent mprotect(PROT_EXEC|PROT_BTI)

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26831

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The release/2.32/master branch has been updated by Szabolcs Nagy
<nsz@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=33dc30bc838b12183744746de102da8b76b9b1d0

commit 33dc30bc838b12183744746de102da8b76b9b1d0
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date:   Tue Dec 1 10:13:18 2020 +0000

    aarch64: Use mmap to add PROT_BTI instead of mprotect [BZ #26831]

    Re-mmap executable segments if possible instead of using mprotect
    to add PROT_BTI. This allows using BTI protection with security
    policies that prevent mprotect with PROT_EXEC.

    If the fd of the ELF module is not available because it was kernel
    mapped then mprotect is used and failures are ignored.  To protect
    the main executable even when mprotect is filtered the linux kernel
     will have to be changed to add PROT_BTI to it.

    The delayed failure reporting is mainly needed because currently
    _dl_process_gnu_properties does not propagate failures such that
    the required cleanups happen. Using the link_map_machine struct for
    error propagation is not ideal, but this seemed to be the least
    intrusive solution.

    Fixes bug 26831.

    Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
    (cherry picked from commit cd543b5eb3642d76e365a131ce676f31fe3f1dd4)

-- 
You are receiving this mail because:
You are on the CC list for the bug.