Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dynamic linking

drewdevault.com

Post reply on HN
Print view View original

131–140 of 249 posts

Re: Dynamic linking

#131

Post by wahern »

saagarjha wrote: post #83
wahern wrote: post #3

Do any Linux/glibc or Linux/musl systems support static PIE binaries, yet? Without static PIE support you don't benefit from ASLR (at least not fully). This 2018 article seems like a good breakdown of the issues: https://www.leviathansecurity.com/blog/aslr-protection-for-s... OpenBSD has supported static PIE since 2015; not just supported, but all system static binaries (e.g. /bin and /sbin) are built as static PIEs,…

I'm not sure I understand the first link you posted: if a binary is statically linked, why does it need a GOT? It's literally calling functions in its own binary…

But where in its own binary? To support ASLR of code (a ROP mitigation), especially fine-grain randomization, function call sites can't use static addressing, either absolute or relative, pointing directly to a function. To support ASLR of code you can either rewrite every function call site on load (kinda similar to DLLs on Windows), or use one or more tables that are updated at runtime (PLTs, GOT, etc). BSD and Linux environments use the PLT/GOT approach because 1) it's a better fit for ELF, 2) shares most of the preexisting instrumentation with dynamic linking, and 3) preserves the ability to share most of the mapped pages of static binaries (imagine if a static /bin/sh was effectively rewritten on every invocation). Trying to accomplish this safely and effectively is what RELRO is about. See https://www.redhat.com/en/blog/hardening-elf-binaries-using-... But RELRO poses some dilemmas regarding performance, and depending on your choices as well as the details of the implementation, RELRO might be ineffective or, worse, introduce exploits of its own. See https://www.usenix.org/system/files/conference/usenixsecurit...

It's difficult to achieve a design that provides all the desirable exploit mitigations without sacrificing startup latency and other features. OpenBSD added a new syscall, kbind (https://man.openbsd.org/kbind), so that they can have lazy binding without being susceptible to the RELRO exploits mentioned in that Usenix paper. (Unfortunately, the 2018 leviathansecurity.com article fails to mention kbind, even though kbind was added to OpenBSD in 2015.) There are other approaches. I think the PaX Team has written quite alot about their preferred techniques. But the point is that static PIE, which is desirable because of ASLR and other reasons (e.g. unification of code generation techniques), touches upon varying and distant components of toolchains and runtimes.

Re: Dynamic linking

#132

Post by eikenberry »

loeg wrote: post #124
eikenberry wrote: post #114

Earlier quoted context omitted.

But we haven't learned from this as modern, non-make based build systems still suffer from terribly slow compiles. Take Rust for example. I don't know a single project that uses make to build (they all use cargo), yet Rust suffers from extremely slow compile times. Much of this (as far as I understand) comes from the LLVM compiler, which is why I was picking on compilers.

Rust's slow builds come from rustc, which is based on LLVM. Other LLVM frontends, like clang, are not as slow. This is in part because borrow-checking has a cost.

I've seen several LLVM backed languages that suffered from Slow compile tiles (eg. a recent post on Crystal mentioned this) and thought it was generally attributed to LLVM. And I hadn't heard anyone talk about clang as being fast and even you seem to be saying it is still slow, just not as slow as others (damning with faint praise?).

Re: Dynamic linking

#133

Post by yjftsjthsd-h »

majewsky wrote: post #122
yjftsjthsd-h wrote: post #96

Earlier quoted context omitted.

To be fair, you're not really supposed to be shipping a full system in a docker image if you can help it; you're supposed to layer your application over the smallest base that will support it (whether that's scratch, distroless, alpine, or a minimal debian base). Of course, I'll be the first to agree that "supposed to" and reality have little in common; if I had a dollar for every time I've seen a final image that st…

In my experience, most who build fat images with the compiler chain and everything do so because they're simply not aware that multi-stage builds are a thing now.

Yep. And just general awareness of how Docker works and how to best use it. And that's not a knock on them; it's a whole topic unto itself, and lots of these folks are developers who are just trying to get their stuff working without having to go off and learn all about Docker, and I have a hard time blaming them for that. Which, of course, is why they keep a handful of us sysadmin folks on staff to help tidy up;)

Re: Dynamic linking

#134

Post by deathanatos »

eeereerews wrote: post #36
rumanator wrote: post #19

Earlier quoted context omitted.

> Dynamically linking against something in the long tail is pretty pointless though. I disagree. Dynamic linking, in the context of an OS which offers a curated list of packages in the form of an official package repository, means that a specialized third party is able to maintain a subcomponent of your system. This means you and me and countless others are able to reap the benefit of bugfixes and security fixes prov…

It can also cut the other way though. Bugs can be introduced, compatibility can be broken, users can not find the library in their package manager, or they may find too new of a version. The danger of this is smaller for popular libraries, but goes up as you move to the long tail.

Bugs & compatibility issues are still a problem with the statically-linked version, unless you want to stay on the version of the library with the security vulnerability, you have to upgrade. That means, for either static or dynamic, dealing with bugs and compatibility issues — which I'd argue is another form of bug; if you're practicing semantic versioning (which you should be, as it prevents exactly this issue), this indicates either someone accidentally broke compatibility (a bug in the library), or someone was relying on something outside the established API (a bug in the consumer). For major versions (i.e., where compatibility is intentionally broken), good package managers are able to manage side-by-side installation of well-behaved packaged. (E.g., Portage's "slots" concept.) I'd also mention Nix's design here; my understanding is that it allows you to upgrade the dependency for just some consumers, so you really can then choose between insecure & bugs.

Re: Dynamic linking

#135

Post by kick »

saagarjha wrote: post #77
kick wrote: post #66

Earlier quoted context omitted.

This comment hits all of the boxes for everything that is wrong with Hacker News. "First, false statement. Since you know false assumption, I would false conclusion. And of course, this means false conclusion. I'd like to see analysis done on what you did them on." "Second, the arguments seem a little cherry-picked. "Quote from article about W and Z" is cute. But modern systems have a lot of Z, and Obviously You Didn…

I know it's a popular Hacker News trope, but when done well I actually appreciate comments of the style "the author does a comparison and has some results, but do also keep in mind xyz that is non-obvious". I know there is a problem with people who go through articles and try to pick things that could affect the results and treat that as invalidating them, but more often than not simple comparisons like these do have…

This one in particular was done terribly, and is imitating ones in the same style. I don't dislike the act of disagreement, nor even disagreements in this vein, I dislike the act of being confident, and further condescending ("is cute"), while making so many obvious mistakes that could be corrected with even a speck of knowledge about what you're talking about.

Re: Dynamic linking

#136

Post by spacechild1 »

saagarjha wrote: post #123
btilly wrote: post #116

Earlier quoted context omitted.

I prefer that comment to your reply. By a lot. It attempted to apply reason. You only mocked the form the arguments took. I am firmly of the opinion that content is more important than form. That comment did make a major mistake. Arch Linux is not a source distribution. But the mistake notwithstanding, it was otherwise well-reasoned. Your response was not. You can mock the point that there is still a benefit in shari…

> I am firmly of the opinion that content is more important than form. This is quite possibly the stupidest thing I have heard this year. How could you possibly have come up with something that brain-dead? Is this how you normally are, or did you have to reach deep into your mind to find the most inane thing you could possibly say and pollute Hacker News with it? Goodness, I hope so. I don't even want to think about…

You're being unnecessarily rude.

Re: Dynamic linking

#137

Post by loeg »

saagarjha wrote: post #123
btilly wrote: post #116

Earlier quoted context omitted.

I prefer that comment to your reply. By a lot. It attempted to apply reason. You only mocked the form the arguments took. I am firmly of the opinion that content is more important than form. That comment did make a major mistake. Arch Linux is not a source distribution. But the mistake notwithstanding, it was otherwise well-reasoned. Your response was not. You can mock the point that there is still a benefit in shari…

> I am firmly of the opinion that content is more important than form. This is quite possibly the stupidest thing I have heard this year. How could you possibly have come up with something that brain-dead? Is this how you normally are, or did you have to reach deep into your mind to find the most inane thing you could possibly say and pollute Hacker News with it? Goodness, I hope so. I don't even want to think about…

The content here is you being an ass.

Re: Dynamic linking

#138

Post by kick »

cryptonector wrote: post #93
kick wrote: post #66

Earlier quoted context omitted.

This comment hits all of the boxes for everything that is wrong with Hacker News. "First, false statement. Since you know false assumption, I would false conclusion. And of course, this means false conclusion. I'd like to see analysis done on what you did them on." "Second, the arguments seem a little cherry-picked. "Quote from article about W and Z" is cute. But modern systems have a lot of Z, and Obviously You Didn…

Actually, this is a very serious topic, and TFA is wrong in a number of ways. HN commenters being able to say so is everything that's right with HN. My own commentary on TFA is all over the comments on this HN post. I put more effort and detail into my comments on this post than GP, but GP is not wrong. Commenting that a comment is exemplary of all that's wrong with HN is... popular, I'll grant you that, but it grate…

HN commenters being able to say so is everything that's right with HN.

This would be correct, if the objection were right. But the commentator was objectively incorrect, in a way that could have been avoided with something as small as a web search, and the comment had the audacity to do so in a condescending way. I didn't knock anyone who had a genuine objection to the post, I replied to an incredibly low-effort and low-quality comment pointing out that it was low-effort and low-quality.

Commenting that a comment is exemplary of all that's wrong with HN is... popular, I'll grant you that, but it grates, and it's not really right.

This is the first one I've ever made, and I post pretty frequently. I don't think it's wrong whatsoever, and I'm standing by it.

It's a "shut up" argument.

It absolutely is a "shut up" argument. Comments should not be written when they can't get the simplest of facts straight, and authors of them should think before they post.

No need to disparage commenters.

I didn't, I disparaged their comment. I don't think doing so was wrong, either, because the comment was practically equivalent to replying to a well-considered post with a PNG of a meme.

Re: Dynamic linking

#139

Post by loeg »

eikenberry wrote: post #132
loeg wrote: post #124

Earlier quoted context omitted.

Rust's slow builds come from rustc, which is based on LLVM. Other LLVM frontends, like clang, are not as slow. This is in part because borrow-checking has a cost.

I've seen several LLVM backed languages that suffered from Slow compile tiles (eg. a recent post on Crystal mentioned this) and thought it was generally attributed to LLVM. And I hadn't heard anyone talk about clang as being fast and even you seem to be saying it is still slow, just not as slow as others (damning with faint praise?).

I don't have good data for this, but Clang is much faster compiling C than C++, for example. I don't know if it's fast or slow in any absolute sense; it's not too far off from GCC time-wise and produces approximately-as-good optimized code for my purposes.

Re: Dynamic linking

#140

Post by kick »

spacechild1 wrote: post #136
saagarjha wrote: post #123

Earlier quoted context omitted.

> I am firmly of the opinion that content is more important than form. This is quite possibly the stupidest thing I have heard this year. How could you possibly have come up with something that brain-dead? Is this how you normally are, or did you have to reach deep into your mind to find the most inane thing you could possibly say and pollute Hacker News with it? Goodness, I hope so. I don't even want to think about…

You're being unnecessarily rude.

The point of the first half of his comment was very obviously pointing out that "form is less important than content" is wrong; Saagar wasn't doing it for no reason, and wasn't doing it in bad faith. That's why it was in an entirely different tone than the rest of the comment, and just about every other comment he's ever made on this site.
Post reply on HN