Soller: Real hardware breakthroughs, and focusing on rustc

Posted Dec 3, 2019 12:00 UTC (Tue) by anton (subscriber, #25547)
In reply to: Soller: Real hardware breakthroughs, and focusing on rustc by Wol
Parent article: Soller: Real hardware breakthroughs, and focusing on rustc

And saving space by not pulling in all of a megabyte library because they just want to use one routine?

Do you mean pulling into the executable file, or pulling into RAM? In either case, what you imply does not happen:

A shared library is not pulled into the executable file of the program at all.
If only one routine is used, only the pages that contain the executed code of that routine is demand-paged into RAM.

The rest of your claim are off-mark, too. Static linking does not give you ASLR at all. If you disable ASLR in the kernel, a statically-linked binary always gets loaded to the same position and is therefore no better than with dynamic linking; conversely, if you do not disable ASLR, all the code (including the shared libraries) is ASLRed.

Your comment about "load the library a couple of times to resolve all the references" is so wrong that I wonder if I misunderstand what you mean.

Finally, if one routine in a library has a vulnerability, that vulnerability can only ever be used by an attacker if the program actually calls it, no matter how the routine was linked. And if the program calls it, it will certainly be there even with static linking.

Soller: Real hardware breakthroughs, and focusing on rustc

Posted Dec 3, 2019 14:46 UTC (Tue) by farnz (subscriber, #17727) [Link]

There are, however, two real space savings:

Each library you use increases memory use by at least one page (for the code page), possibly more if you also need to bring in data pages; if the function you want is smaller than a page, then linking it in directly is cheaper. This adds up if you use a lot of libraries - static linking can "tail pack" the libraries, dynamic has to have wasted space instead.
LTO and inlining can reduce the total code you pull in; the function (out-of-line) might be 2k of code + data, but after inlining and LTO, you only bring in 800 bytes to cover the cases you care about. This especially applies to a language like C++, where monomorphization can take place during the LTO process, removing code that's only needed for certain data types.

Soller: Real hardware breakthroughs, and focusing on rustc

Posted Dec 3, 2019 16:41 UTC (Tue) by excors (subscriber, #95769) [Link]

> Finally, if one routine in a library has a vulnerability, that vulnerability can only ever be used by an attacker if the program actually calls it, no matter how the routine was linked. And if the program calls it, it will certainly be there even with static linking.

That's true, though I think unused code (whether vulnerable or not) can still be useful in exploits when there is a vulnerability in the actively-used parts of the program. A buffer overflow bug might allow a ROP attack, but the attacker needs to find suitable ROP gadgets somewhere in the process's address space. And some Spectre variants trick the CPU into speculatively executing code at attacker-controlled addresses, but that code must contain a gadget to exfiltrate data from the speculative world. If the application is statically linked and the dead code is removed, it becomes harder for an attacker to find suitable gadgets. (But in practice I guess this is only significant for small applications that use large libraries; if it's a large application then it'll probably have enough gadgets already.)

Soller: Real hardware breakthroughs, and focusing on rustc

Posted Dec 3, 2019 17:14 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

> Do you mean pulling into the executable file, or pulling into RAM? In either case, what you imply does not happen:

If I'm distributing a program, I have to include shared libraries. They may already be on the system, but ...

And while only the required routines may be pulled into ram, they are memory-mapped, and depending on your page size rather more may be pulled in than required.

> Static linking does not give you ASLR at all.

Do you mean the locations are randomised every time the application is run? In which case you're right, although there is nothing stopping a static loader from doing the same.

> Your comment about "load the library a couple of times to resolve all the references" is so wrong that I wonder if I misunderstand what you mean.

You may well do. Remember I'M DISCUSSING ALTERNATIVES TO LINUX. When the linker loads the master object, it creates a load of dangling references. When it loads a library to resolve those references, it *only* resolves those references, so if one library routine calls another it may create a new dangling reference - which means the library needs to be loaded again to resolve it! Don't forget - the library is a collection of independent binary blobs and only those blobs that are needed are copied into the executable.

> Finally, if one routine in a library has a vulnerability, that vulnerability can only ever be used by an attacker if the program actually calls it, no matter how the routine was linked.

So you're saying that, even though a dynamic library is memory-mapped, an attacker can't jump to an arbitrary position in that library?

Cheers,
Wol

Soller: Real hardware breakthroughs, and focusing on rustc

Posted Dec 8, 2019 15:37 UTC (Sun) by nix (subscriber, #2304) [Link]

> You may well do. Remember I'M DISCUSSING ALTERNATIVES TO LINUX. When the linker loads the master object, it creates a load of dangling references. When it loads a library to resolve those references, it *only* resolves those references, so if one library routine calls another it may create a new dangling reference - which means the library needs to be loaded again to resolve it! Don't forget - the library is a collection of independent binary blobs and only those blobs that are needed are copied into the executable.

The problem here is that your terminology is so wrong that people who know the terminology can barely understand what you're saying. You're talking about gcc -lfoo -lbar -lfoo, right? That's not loading. That's linking. Loading is what ld.so does at runtime, and it never loads libraries more than once in the common case (modulo very obscure cases like dlmopen() and audit libraries).