Re: [PATCH v2] x86-64: Check if mprotect works before rewriting PLT

["H.J. Lu" <hjl.tools@gmail.com>]

On Tue, Jan 16, 2024 at 9:36 AM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 12/01/24 15:19, H.J. Lu wrote:
> > Systemd execution environment configuration may prohibit changing a memory
> > mapping to become executable:
> >
> > MemoryDenyWriteExecute=
> > Takes a boolean argument. If set, attempts to create memory mappings
> > that are writable and executable at the same time, or to change existing
> > memory mappings to become executable, or mapping shared memory segments
> > as executable, are prohibited.
> >
> > When it is set, systemd service stops working if PLT rewrite is enabled.
> > Check if mprotect works before rewriting PLT.  This fixes BZ #31230.
> > This also works with SELinux when deny_execmem is on.
>
> On musl channel Rich has raised some points for this optimization that
> made me curious.  His main points are this should not be faster than
> -fno-plt, so the main advantage is for old binaries or environments

That is true for most cases.   But in some cases, direct call + direct
jump is faster than indirect call.

> where PLT is required (either for audit or any other instrumentation).

This is also true.

> Since this new tunable requires more resources (either for the probing,
> plus the setup itself, and the extra VMA for the new PLT rewrite), with
> recent  Linux security modules that would most likely to prevent it in
> a lot of deployments; the question is how really useful this would be

This also applies to all JITs.

> and whether this is really more like an experiment to show a new x86
> feature.

This feature has a minimal performance impact for most people.  But
it is very useful for cases where PLT performance is critical.

-- 
H.J.