Am 05.04.22 um 11:51 schrieb Jan Engelhardt:

On Tuesday 2022-04-05 11:24, Marcus Meissner wrote:

...

SUSE has built everything with "Partial RELRO" for a long time (via a default in binutils). (-z relro)

We did not yet do "Full RELRO" (-z now) as we feared the amount of integration work.

The way the manpages are written, one would not think of -z now (or ld.so LD_BIND_NOW) having ties to relro, but be more of a debugging aid, so that debugger sessions don't go through the symbol resolution trampolines. There has got to be some speed penalty when a process that received libstdc++.so.6 by "accident" now has to resolve 6000ish symbols even if unused.

Is that what happens? I thought it would only resolve the symbols that are used, and "resolve all symbols" means resolving all symbols that need to be resolved, i.e. are listed in .dynsym of some loaded ELF file. For unused functions there is no GOT/PLT, so where would the dynamic linker write their result? The second part, "or when the shared library is loaded by dlopen, instead of deferring function call resolution to the point when the function is first called", is probably referring to the .dynsym of that library, i.e. we resolve whatever it uses. I don't think it will precache dlsym results, what would be the point of that? The function pointer returned is stored by the user wherever they want, which will likely be writable pages. But I haven't actually debugged or traced this. In any event, the man page does indeed not mention any security benefits, though it's well-known that it makes the relocation section read-only. (I always forget which one but I think it's .rela.plt.) Aaron

Am 07.04.22 um 13:05 schrieb Jan Engelhardt:

On Thursday 2022-04-07 02:19, Aaron Puchert wrote:

...

...

...

We did not yet do "Full RELRO" (-z now) as we feared the amount of integration work. The way the manpages are written, one would not think of -z now (or ld.so LD_BIND_NOW) having ties to relro, but be more of a debugging aid, so that debugger sessions don't go through the symbol resolution Is that what happens? I thought it would only resolve the symbols that are used, and "resolve all symbols" means resolving all symbols that need to be resolved, i.e. are listed in .dynsym of some loaded ELF file I did not mean to contradict; indeed there are different interpretations for "all" and "used".

- symbols in .dynsym of a library (libstdc++ roughly 5971) - symbols in .rela.dyn/.rela.plt/.dynsym section of an executable (hello world[1] in c++: up to 14 depending on what you count) Good point, the .rela.* sections are probably more appropriate when estimating the cost, since symbols in .dynsym don't need to be looked up necessarily. (If they're defined in the library but not used there, or if the library uses -fno-semantic-interposition.) - set of functions that actually get invoked during runtime (if rand yields 0, cout.operator<< won't be called, so it need not be resolved) Indeed, “used” can mean statically used or dynamically used, and neither necessarily implies the other. (Statically used symbols might not be needed in a particular execution, and dynamically used symbols might have been resolved with dlsym.)

There could be quite a number of functions that aren't used in a particular invocation of an executable, which I guess could happen especially in scripts. Then on the other hand, looking up all statically used functions at once might be more cache-friendly.

[1] #include <iostream> #include <cstdlib> int main() { srand(time(nullptr)); if (rand() & 1) std::cout << "Hello world\n"; }

LD_BIND_NOW=1 LD_DEBUG=symbols ./a.out 2>&1|grep -i symbo|sort -u|wc -l 6302 LD_BIND_NOW=0 LD_DEBUG=symbols ./a.out 2>&1|grep -i symbo|sort -u|wc -l 4044

Strangely I get 6300 for both and I haven't updated to the “-z now by default” snapshot yet. But either way there is an awful lot of symbols used by libstdc++. Aaron

On Tue, Apr 5, 2022 at 2:17 PM Cristian Rodríguez wrote:

You should also note that you will not be able to interpose symbols anymore, you need to relink everything again to do so.

Before somebody asks why it is because LD does PLT elision at build time.. it changes PLT->GOT when -z now since the whole reason for the existence of PLT is lazy binding.

On Wed, Apr 6, 2022 at 8:54 PM Aaron Puchert wrote:

Can you elaborate on this? The GOT is still filled out by the dynamic linker, so if the linker thinks a symbol should be interposed (and the logic behind interposition is architecture-independent of course), why can it not write the address of a different function into the GOT?

https://github.com/bminor/binutils-gdb/blob/5f0b6b77f11ca1484b69babd7ab6729e... contains the logic .. apparently it no longer does it depending on BIND_NOW..it used to..but was apparently reverted because it broke LD_AUDIT.. Huh.. so I have to use Wl,-Bsymbolic-functions then? https://media.giphy.com/media/ToMjGpx9F5ktZw8qPUQ/giphy-downsized-large.gif -fvisibility=protected did not work the last time I tried either.

Hello, On Thu, 7 Apr 2022, Aaron Puchert wrote:

Am 05.04.22 um 20:24 schrieb Cristian Rodríguez:

...

On Tue, Apr 5, 2022 at 2:17 PM Cristian Rodríguez wrote:

...

You should also note that you will not be able to interpose symbols anymore, you need to relink everything again to do so.

That's not true. The only real effect that -znow has is to set the DT_BIND_NOW flag in the produced component (shared lib or executable). And that simply makes ld.so resolve all relocations from that component to be resolved at load time, instead of lazily. -znow does _not_ change the ELF interposition and visibility rules in any way. Just because it came up in the thread: do note that the PLT is not for enabling interposition, it's for enabling lazy binding. Interposition is also possible without a PLT, as it always was for e.g. data symbols. So, it doesn't matter (for interposition) if the PLT is now used or not. With -znow it would be possible to avoid the PLT by essentially inlining it: callit(); would be translated roughly to callq *GOT[id_of_callit] (instead of 'callq plt_slot_of_callit'), and at that GOT slot a normal relocation to symbol 'callit' would be recorded. And that one is (with znow) resolved at load time, instead of by the PLT slot calling into the dynamic linker. That scheme can break certain assumptions (e.g. from LD_AUDIT), so it's not done. But even if it were done it wouldn't break interposition. Now, there are contrived examples where znow changes something. You basically need to construct examples where the final outcome of symbol resolution depends on timing: i.e. if the resolved symbol changes from load time compared to somewhen later. One could imagine a component calling foobar() (which may have a definition in say libfoo), and then a dlopen'ed component is also defining foobar. Now with lazy loading foobar would be only resolved at call time, and hence when that occurs (for the first time) after the dlopen, _and_ that dlopen is done in a very specific way so that that component comes in front of libfoo (which isn't normally the case) then foobar will be resolved to the dlopen-component instead of libfoo. With znow it will always resolve to the definition in libfoo (because the dlopen hadn't happened yet).

...

Before somebody asks why it is because LD does PLT elision at build time.. it changes PLT->GOT when -z now since the whole reason for the existence of PLT is lazy binding.

Can you elaborate on this? The GOT is still filled out by the dynamic linker, so if the linker thinks a symbol should be interposed (and the logic behind interposition is architecture-independent of course), why can it not write the address of a different function into the GOT?

And this is exactly what would happen if the PLT would be elided^Winlined and hence also not break interposition. As you note the PLT is still used on x86-64 though, for other reasons. To wit: % cat app.c extern void interpose_this(void); int main() { interpose_this(); return 0; } % cat lib.c void interpose_this(void) { } % cat interpose.c extern int printf(const char *, ...); void interpose_this(void) { printf("it works\n"); } % gcc -Wl,-z,now -fPIC -shared -o interpose.so interpose.c % gcc -Wl,-z,now -fPIC -shared -o liblib.so lib.c % gcc -Wl,-z,now -Wl,-rpath,. app.c -L. -llib % ./a.out % LD_PRELOAD=interpose.so ./a.out it works So, it works, like it says there ;-) Ciao, Michael.