Automatic use of glibc-hwcaps for plugins in dlopen

Automatic use of glibc-hwcaps for plugins in dlopen

[Thiago Macieira]

If the discussion on a naming convention for plugins makes a recommendation, 
the next question of mine is whether we should expand dlopen() to make use of 
the convention and the fact it knows the hwcaps that allow an ELF module to be 
loaded or not.

Currently, the vast majority of *plugins* are not stored directly in $LIB, but 
in a subdirectory or somewhere else specified by a framework-specific 
configuration or environment variable, like PYTHONPATH or QT_PLUGIN_PATH. That 
means those frameworks will issue dlopen() calls that contain the slash 
character and that disables hwcaps. (There are good reasons for that, notably 
security, which we must keep in mind.)

This means that plugin frameworks will not automatically find higher-ISA 
plugins if we come up with a recommendation. Each and every one of them needs 
to be modified to know what to look for and how to test the hardware 
capabilities to match. We've done it in Clear Linux, but that's sub-optimal.

So, can dlopen() do this for us?

And should it be implicit? Having to modify the dlopen calls to pass an extra 
RTLD_SEARCH_HWCAPS flag is an acceptable price. It'll lead some copy pasting, 
but at least it's trivial.

What security concerns should be applied? For example, should dlopen confirm 
that the ownership of the new file is the same as that of the baseline one?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

Re: Automatic use of glibc-hwcaps for plugins in dlopen

[Florian Weimer]

* Thiago Macieira via Libc-alpha:

> So, can dlopen() do this for us?
>
> And should it be implicit? Having to modify the dlopen calls to pass
> an extra RTLD_SEARCH_HWCAPS flag is an acceptable price. It'll lead
> some copy pasting, but at least it's trivial.

It's either that, or changing what's on disk, at the file system
specified by the pathname argument: that ELF file could have some
property that triggers hwcaps searching, or it could be a non-ELF file,
or even a directory.

But the flag-based approach is much simplier and more compelling.  We
should use a more general name, though, making clear that other
side-ways lookups may occur, and that it's the responsibility of the
dlopen caller to make sure that directory containing the loaded object
is trusted.

> What security concerns should be applied? For example, should dlopen
> confirm that the ownership of the new file is the same as that of the
> baseline one?

I don't think that's useful because file ownership does not tell us
anything about provenance.

Thanks,
Florian

Re: Automatic use of glibc-hwcaps for plugins in dlopen

[Thiago Macieira]

On Wednesday, 20 October 2021 01:39:15 PDT Florian Weimer wrote:
> It's either that, or changing what's on disk, at the file system
> specified by the pathname argument: that ELF file could have some
> property that triggers hwcaps searching, or it could be a non-ELF file,
> or even a directory.

And ELF property requires modifying the output and that's not easy to do from 
the distro's packages perspective. Replacing with a text file is. We do that 
for ld already:

$ cat /lib64/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /usr/lib64/libc.so.6 /usr/lib64/libc_nonshared.a  AS_NEEDED ( /usr/
lib64/ld-linux-x86-64.so.2 ) )

Clear goes further:
$ cat /lib64/libXau.so
INPUT(libX11.so.6)
$ cat /lib64/libICE.so 
INPUT(libX11.so.6)
$ cat /lib64/libSM.so
INPUT(libX11.so.6)
$ cat /lib64/libXext.so
INPUT(libX11.so.6)

A redirecting ELF file so we don't need to have a text parser in dlopen also 
works.

> But the flag-based approach is much simplier and more compelling.  We
> should use a more general name, though, making clear that other
> side-ways lookups may occur, and that it's the responsibility of the
> dlopen caller to make sure that directory containing the loaded object
> is trusted.

Makes sense to me. Like I said, lots of:

#ifndef RTLD_SEARCH_MORE
#  define RTLD_SEARCH_MORE 0
#endif

> > What security concerns should be applied? For example, should dlopen
> > confirm that the ownership of the new file is the same as that of the
> > baseline one?
> 
> I don't think that's useful because file ownership does not tell us
> anything about provenance.

No, but it prevents replacement attacks and symlink attacks in the path name.

BTW, any chance of dlopenat()?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering