Re: Annotate Deprecated Functions in libselinux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 27, 2020 at 2:43 PM Ulrich Drepper <drepper@xxxxxxxxxx> wrote:
>
> On 2/27/20 9:03 PM, Ondrej Mosnacek wrote:
> > Ulrich, could you help us understand the macros you proposed to add to
> > the SELinux libraries (probably a very long time ago)? Specifically,
> > we are talking about those defined in "dso.h" header files such as
> > this one [1]. See also GH issue 204 [2] for related discussion.
>
> The use of the hidden infrastructure is not just a means to reduce
> overhead in the form of PLTs.  It also ensures that internals for the
> library don't leak out.

Linker script? We just use a map file that has everything local except for what
we want to export.

> If calls between functions within the same DSO
> use the PLT they can be intercepted by DSO earlier in the search path of
> the dynamic linker.  This can have unwanted consequences.

Huh? I'm not following? If we just remove this, what would actually
break in libselinux?

>
> I advise that this isn't changed.  The infrastructure to do this should
> change, though.  You could look at the code glibc uses today.  The
> functionality is still there, just slightly changed.
>
> An alternative is to use gcc's -fno-semantic-interposition option.  This
> should ensure that PLT entries are avoided.  For Python this was used to
> achieve significant speedups due to the PLT reduction.  I know you don't
> care about speed that much but this is a way to achieve it.  Python uses
> LTO but since the compiler is told about the symbol use there are not
> problems.

This minor overhead on the first call to a routine to resolve the symbol isn't
really much overhead. After it's resolved its like an extra jmp or something.

If you really wanted to avoid relocation, couldn't you just link statically?

This seems like it might be good for specific issues, but I don't see how this
infrastructure really prevents or fixes anything besides complicating the code,
perhaps enlighten me?

I can see how perhaps for large things like python/glibc it could be
useful but for
libselinux this just seems like an over-engineered solution to a
non-existent problem.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux