5 ms·

GNU IFUNC is the real culprit behind CVE-2024-3094

132 points by foltik 5mo ago

washingupliquid 5mo ago
> Why do Linux Distros modify OpenSSH? > The short answer is that they have to. OpenSSH is developed by the OpenBSD community, for the OpenBSD community, and they do not give a flying Fedora about Linux. What complete horseshit. I stopped reading there. The OpenSSH Portable branch is maintained by OpenBSD developers and SystemD is a completely optional add-on so why on earth would they make it a dependency? If they didn't care about the Linux community they wouldn't develop this software *for free* for them. They can go write their own GNU SSH then. It certainly doesn't help that there are 165+ definitions of what constitutes a "complete GNU+Linux system" some of which use SystemD and some which vow never to. It's not the OpenBSD developers' fault some Linux distros use overly complex plumbing and can't agree on one standard for their OS unlike every other OS out there, including Windows. The xz backdoor was a Debian and Red Hat issue because they maintained patches to fix problems of their own creation. No one else was affected. Why should the OpenBSD people care? It's not their problem.
- striking 5mo ago
  The OP agrees with you... if you continue reading, they wrote > These patches never went into Portable OpenSSH, because the Portable OpenSSH folks were ["not interested in taking a dependency on libsystemd"](link). And they never went into upstream OpenSSH, because OpenBSD doesn't have any need to support SystemD. The language may have been harsher than it needed to and therefore could be more easily misunderstood, but I believe you are actually in agreement with them
  - washingupliquid 5mo ago
    It makes it sound even worse, cherry picking language like "not interested" as if the OpenBSD folks should shoulder blame for not being altruistic enough. It reeks of trashing your benefactor, who gave you well-written free software, which you then made insecure with your own patches. If you remove the roof of your car with a chainsaw and are inevitably injured later, is it the car manufacturer's fault they didn't offer that model as a convertible from the factory? The better question is why are people still trying to assign blame all these years later? The IT world dodged a bullet but has moved on (and likely didn't learn from their mistakes as supply chain attacks are steadily increasing).
    - striking 5mo ago
      Okay. You could see it that way. Or you could read what the author wrote about who is to blame: > No one person or team really made a mistake here, but with the benefit of hindsight it's clear the attackers perceived that the left hand of Debian/Fedora SSH did not know what the right hand of xz-utils was doing. with OpenBSD not even being mentioned here
    - debazel 5mo ago
      I guess it's up to interpretation, but I read it the complete opposite way, as in Linux distributions should not think so highly of themselves as to expect OpenBSD to conform and adapt to their mess, and OpenBSD rightfully should not be expected to "give a flying Fedora about Linux".
      - robertdfrench 5mo ago
        [dead]
- jmclnx 5mo ago
  >Did the OpenSSH folks know (or care) that ifunc was a thing? It's certainly not a thing on OpenBSD. I do not know why you were down-voted, maybe you deserved no up-votes, but down-votes to me were a bit extreme :) But that quote tends to indicate to me the author put a little blame on OpenSSH Developers. Maybe the author did not intend it to be read in the way I read it. OpenSSH developers should not need to know what or why systemd distros apply patches to OpenSSH, the distro I use, Slackware, did not have this vulnerability because the Slackware team, AFAIK, only adds patches if the package does not compile. If other distros did that this issue would not have occurred. To me the issue was patching OpenSSH for some systemd thing. Maybe IFUNC was part of the issue, but the real issue was patching OpenSSH. But I know one thing, I never heard of IFUNC and after reading about it, I will avoid that as much as I can. So at least I was educated :)
  - robertdfrench 5mo ago
    I do not think the OpenSSH folks are at fault! I was trying to drive the point that OpenSSH was forced to work in an environment that is very, very different from where it is primarily developed. I don't think the OpenSSH folks should have been expected to anticipate something as genuinely unusual as ifunc, since there is no analog on OpenBSD.
warmdarksea 5mo ago
seeing LD_PRELOAD in the "less-exploitable alternatives to GNU IFUNC" section was kind of funny
- stabbles 5mo ago
  Yeah, that suggestion made me roll my eyes. It's the wrong granularity, there's no build system support, it's inconvenient (executable wrappers? require the user to understand all transitive deps?). It also fails to mention glibc-hwcaps, which would've been a cleaner solution in the context.
  - robertdfrench 5mo ago
    Ohhh I had no idea about hwcaps! This is great! That is the way to solve this problem.
wahern 5mo ago
1) IFUNC is hardly the only way to run code before main. 2) The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process, whereas with IFUNC the GOT will eventually be made immutable (or can be... not sure if that's the default behavior). In general function pointers aren't great for security unless you explicitly make the memory backing the pointer(s) unwritable, which at least is easier to do for a global table than it is for things like C++ vtables (because there's the extra indirection through data pointers involved to get to the table).
- ajross 5mo ago
  Yeah, this blog is misguided. As a higher level criticism: it's confusing[1] the technical details with the payload with the exploit chain that deployed it. The interesting thing is obviously not that you can get code to run at high privilege level by modifying a system component. I mean, duh, as it were. The interesting thing is that the attackers (almost) got downstream Linux distros to suck down and deploy that malicious component for them. And that's not down to an oddball glibc feature, it happened because they got some human beings to trust a malicious actor. GNU glibc can't patch that! [1] Incorrectly, as you point out.
- ordu 5mo ago
  > The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process The article mentions this, and also points to mprotect which you can use to protect the pointer. Why people jump to criticize without reading first? BTW, you can ask an LLM to check your critique, before posting, if you don't want to read the text.
  - IAmLiterallyAB 5mo ago
    Yes but at best their "solution" is equally secure, not any better.
    - kstrauser 5mo ago
      Would xz still have been able to alter opensshd without IFUNC?
TacticalCoder 5mo ago
[flagged]
- k_roy 5mo ago
  > systemd is a monstrous codebase and there lies shitload of exploits in it. Either intentional or accidental. And yet... 1. practically all hyperscalers use it 2. desktops 3. container images, that power everything from docker to kubernetes use it It helps that it's actively maintained, battle-tested as hell, and widely audited. Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack.
  - lmm 5mo ago
    > Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack. Can you even imagine pypi or npm compromising ssh this way?
    - k_roy 5mo ago
      > Can you even imagine pypi or npm compromising ssh this way? Is ssh somehow sacrosanct in a way that any other RCE or credential stealing attack is different? I don’t even know the last time I exposed ssh to the open internet. But the fact with npm or pypi you can be exploited just by running the software you’ve already installed because the dependencies are everywhere on your system?
      - lmm 5mo ago
        > Is ssh somehow sacrosanct in a way that any other RCE or credential stealing attack is different? I see ssh as a very fundamental part of the system - in BSD terms it's in base not ports. Random packages from npm or pypi, sure, if you installed some slop off the internet and got exploited that's not so surprising. (Even those package managers themselves are not part of the base system, much less anything you install with them). But ssh should be safe!
octoberfranklin 5mo ago
Yes, that nefarious nation-state threat actor known as GNU IFUNC! Curses, thwarted again!
- robertdfrench 5mo ago
  I take your meaning, but I think a threat actor targeting a system without IFUNC would be delighted if it suddenly showed up. It's like finding a website with a file upload form that purposefully supports ../ in paths.
phire 5mo ago
This is barking up the wrong tree. Using IFUNC to patch sshd was kind of elegant, it achieved rootkit like behaviour with a pre-existing mechanism. And sure, it might be possible for a secure daemon like sshd to drop enough privileges that it could protect itself from a malicious dynamically linked library. But IFUNC was not required, neither was systemd. The game was lost as soon as the attacker had arbitrary code installed in a semi-common library. It doesn't have to get linked directly with sshd, it only needed to be linked into any program running as root, at least one time. Most programs make zero effort to sandbox themselves, and as soon as one of those links with the malicious library, it could do anything. Like indirectly targeting sshd by patching its binary on disk (optionally hiding it with a rootkit), or using debug APIs to patch sshd in memory. IFUNC, systemd, and the patched openssh are all irrelevant to the issue, that was simply the route this attacker took to leverage their foothold in libxz. There are thousands of potential routes the attacker could have taken, and we simply can't defend from all of them.
- xorcist 5mo ago
  It was not essential to the exploit, but that does not mean it was irrelevant. More commonly used libraries are watched harder. The exploit was made much, much, worse by its indirect use by way of systemd. Approximately nobody wanted that feature and it still went in. That's something we need to be able to discuss.
  - AshamedCaptain 5mo ago
    But the fact that it was done indirectly from systemd has nothing to do with IFUNC.
- belorn 5mo ago
  There is always selinux if we want to add protection against arbitrary code running as root. Just because something operate as root does not mean it must have privileged access to everything.
  - PaulHoule 5mo ago
liamgm 5mo ago
xz-tools should scrap and reimplemented the code to the safer one , current one have safety and performance issue.
somat 5mo ago
Isn't it the same problem with pam. Some solaris engineer got a little too clever and decided that the modular part of the the auth system needed to be dynamic libs. Now it's all in one process space, hard to understand, hard to debug and fragile. I really like openbsd's bsdauth, I don't know if it is actually any better than pam but because it is moduler at the process level it is possible for mere mortals to debug and make custom auth plugins. Sadly only obsd actually uses it. https://man.openbsd.org/login.conf.5#AUTHENTICATION https://man.openbsd.org/login.conf.5#AUTHENTICATION
countWSS 5mo ago
IFUNC should be implemented by software itself, like switching functions on runtime/compile checks. Why bother having a slower, insecure version that is less flexible than a function pointer? I have to agree with author. Glibc is filled with even more nasty hacks ripe for new exploits.
- throwawayqqq11 5mo ago
  I agree so much and wished this was the main focus of the debate. It's more a question of why does this exist in the first place and not of how did they abuse it. Building only from source is the minimum required transparency and a CI/CD pipeline able to manipulate the artifact before release takes this away. I remember the outrage, when serde (i think it was) wanted to ship parts as pre-compiled binaries for build performance reasons...
- pocksuppet 5mo ago
  Less indirection means faster code. If the dynamic loader is already using a level of indirection and you patch into that same indirection instead of adding another, you're not making it slower.
Panzerschrek 5mo ago
> By letting the linker run arbitrary code before main As I know C++ allows running arbitrary code before main too - for constructors of global variables. Does it bring security risks too?
- bonzini 5mo ago
  It does not, it's actually arbitrary code running during the dynamic loading process, i.e. before _start.
  - Panzerschrek 5mo ago
    But what if I have a C++ dynamic library? Does it call constructors for global variables before _start function in the main program starts?
    - bonzini 5mo ago
      _start takes care of calling the global initializers and register the atexit callback for the finalizers. (In practice _start calls __libc_start_main, a libc function that handles all of that).
rurban 5mo ago
Well, also Unicode identifiers, a C11 spec bug, nobody cares to fix. Still in C26, because "users expect Unicode stability", esp. it's bugs.
theteapot 5mo ago
False dichotomy. There was a series of blatant process failures from Github maintainer through Debian package maintainers. IFUNC also bad.
AshamedCaptain 5mo ago
The entire argumentation here is ridiculous. There's a big jump from "IFUNC slightly undermines RELRO" to "IFUNC is the real culprit". You could have gotten all but the same effect spawning a thread from a plain init or C++ constructor. No one should think that any relro, r^x or aslr or anything like this is going to deter anyone who can literally control the contents of the libraries which are linked in. They could, literally, exec a copy of sshd with a patched config if necessary. The title is just clickbait.
- chuckadams 5mo ago
  I think I triggered the posting of this article in a reply elsewhere, to which you gave the same comment. And dammit, you're totally right, there's lots of other ways to stick arbitrary code into the initialization process at load time. Maybe the real problem is linking dependencies by shoving them into the same address space as whatever is using them and calling it a day. Memory-safe languages can help protect that model against accident, but it still takes just one evil insider to steal the keys to the kingdom.
kristjank 5mo ago
I will still hold the decision to link the biggest possible target on every server against the biggest, most privileged daemon on every server, as not very smart indeed.
bla3 5mo ago
I love the recently added "In Response to Hacker News" section.
- robertdfrench 5mo ago
  Take my money!!
deleted 5mo ago
[deleted]
esbranson 5mo ago
IDK I do find it funny the linked project readme is dunking on this thread. And I am again going to mention the book Linkers and Loaders by John R. Levine from 1999, I'm not sure if there's anything comparable to it. How else does anyone know anything about this stuff?

132 points by foltik 5mo ago

> Why do Linux Distros modify OpenSSH? > The short answer is that they have to. OpenSSH is developed by the OpenBSD community, for the OpenBSD community, and they do not give a flying Fedora about Linux. What complete horseshit. I stopped reading there. The OpenSSH Portable branch is maintained by OpenBSD developers and SystemD is a completely optional add-on so why on earth would they make it a dependency? If they didn't care about the Linux community they wouldn't develop this software *for free* for them. They can go write their own GNU SSH then. It certainly doesn't help that there are 165+ definitions of what constitutes a "complete GNU+Linux system" some of which use SystemD and some which vow never to. It's not the OpenBSD developers' fault some Linux distros use overly complex plumbing and can't agree on one standard for their OS unlike every other OS out there, including Windows. The xz backdoor was a Debian and Red Hat issue because they maintained patches to fix problems of their own creation. No one else was affected. Why should the OpenBSD people care? It's not their problem.

striking 5mo ago
The OP agrees with you... if you continue reading, they wrote > These patches never went into Portable OpenSSH, because the Portable OpenSSH folks were ["not interested in taking a dependency on libsystemd"](link). And they never went into upstream OpenSSH, because OpenBSD doesn't have any need to support SystemD. The language may have been harsher than it needed to and therefore could be more easily misunderstood, but I believe you are actually in agreement with them
- washingupliquid 5mo ago
  It makes it sound even worse, cherry picking language like "not interested" as if the OpenBSD folks should shoulder blame for not being altruistic enough. It reeks of trashing your benefactor, who gave you well-written free software, which you then made insecure with your own patches. If you remove the roof of your car with a chainsaw and are inevitably injured later, is it the car manufacturer's fault they didn't offer that model as a convertible from the factory? The better question is why are people still trying to assign blame all these years later? The IT world dodged a bullet but has moved on (and likely didn't learn from their mistakes as supply chain attacks are steadily increasing).
  - striking 5mo ago
    Okay. You could see it that way. Or you could read what the author wrote about who is to blame: > No one person or team really made a mistake here, but with the benefit of hindsight it's clear the attackers perceived that the left hand of Debian/Fedora SSH did not know what the right hand of xz-utils was doing. with OpenBSD not even being mentioned here
  - debazel 5mo ago
    I guess it's up to interpretation, but I read it the complete opposite way, as in Linux distributions should not think so highly of themselves as to expect OpenBSD to conform and adapt to their mess, and OpenBSD rightfully should not be expected to "give a flying Fedora about Linux".
    - robertdfrench 5mo ago
      [dead]
jmclnx 5mo ago
>Did the OpenSSH folks know (or care) that ifunc was a thing? It's certainly not a thing on OpenBSD. I do not know why you were down-voted, maybe you deserved no up-votes, but down-votes to me were a bit extreme :) But that quote tends to indicate to me the author put a little blame on OpenSSH Developers. Maybe the author did not intend it to be read in the way I read it. OpenSSH developers should not need to know what or why systemd distros apply patches to OpenSSH, the distro I use, Slackware, did not have this vulnerability because the Slackware team, AFAIK, only adds patches if the package does not compile. If other distros did that this issue would not have occurred. To me the issue was patching OpenSSH for some systemd thing. Maybe IFUNC was part of the issue, but the real issue was patching OpenSSH. But I know one thing, I never heard of IFUNC and after reading about it, I will avoid that as much as I can. So at least I was educated :)
- robertdfrench 5mo ago
  I do not think the OpenSSH folks are at fault! I was trying to drive the point that OpenSSH was forced to work in an environment that is very, very different from where it is primarily developed. I don't think the OpenSSH folks should have been expected to anticipate something as genuinely unusual as ifunc, since there is no analog on OpenBSD.

warmdarksea 5mo ago

seeing LD_PRELOAD in the "less-exploitable alternatives to GNU IFUNC" section was kind of funny

stabbles 5mo ago
Yeah, that suggestion made me roll my eyes. It's the wrong granularity, there's no build system support, it's inconvenient (executable wrappers? require the user to understand all transitive deps?). It also fails to mention glibc-hwcaps, which would've been a cleaner solution in the context.
- robertdfrench 5mo ago
  Ohhh I had no idea about hwcaps! This is great! That is the way to solve this problem.

wahern 5mo ago

1) IFUNC is hardly the only way to run code before main. 2) The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process, whereas with IFUNC the GOT will eventually be made immutable (or can be... not sure if that's the default behavior). In general function pointers aren't great for security unless you explicitly make the memory backing the pointer(s) unwritable, which at least is easier to do for a global table than it is for things like C++ vtables (because there's the extra indirection through data pointers involved to get to the table).

ajross 5mo ago
Yeah, this blog is misguided. As a higher level criticism: it's confusing[1] the technical details with the payload with the exploit chain that deployed it. The interesting thing is obviously not that you can get code to run at high privilege level by modifying a system component. I mean, duh, as it were. The interesting thing is that the attackers (almost) got downstream Linux distros to suck down and deploy that malicious component for them. And that's not down to an oddball glibc feature, it happened because they got some human beings to trust a malicious actor. GNU glibc can't patch that! [1] Incorrectly, as you point out.
ordu 5mo ago
> The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process The article mentions this, and also points to mprotect which you can use to protect the pointer. Why people jump to criticize without reading first? BTW, you can ask an LLM to check your critique, before posting, if you don't want to read the text.
- IAmLiterallyAB 5mo ago
  Yes but at best their "solution" is equally secure, not any better.
  - kstrauser 5mo ago
    Would xz still have been able to alter opensshd without IFUNC?

TacticalCoder 5mo ago

[flagged]

k_roy 5mo ago
> systemd is a monstrous codebase and there lies shitload of exploits in it. Either intentional or accidental. And yet... 1. practically all hyperscalers use it 2. desktops 3. container images, that power everything from docker to kubernetes use it It helps that it's actively maintained, battle-tested as hell, and widely audited. Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack.
- lmm 5mo ago
  > Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack. Can you even imagine pypi or npm compromising ssh this way?
  - k_roy 5mo ago
    > Can you even imagine pypi or npm compromising ssh this way? Is ssh somehow sacrosanct in a way that any other RCE or credential stealing attack is different? I don’t even know the last time I exposed ssh to the open internet. But the fact with npm or pypi you can be exploited just by running the software you’ve already installed because the dependencies are everywhere on your system?
    - lmm 5mo ago
      > Is ssh somehow sacrosanct in a way that any other RCE or credential stealing attack is different? I see ssh as a very fundamental part of the system - in BSD terms it's in base not ports. Random packages from npm or pypi, sure, if you installed some slop off the internet and got exploited that's not so surprising. (Even those package managers themselves are not part of the base system, much less anything you install with them). But ssh should be safe!

octoberfranklin 5mo ago

Yes, that nefarious nation-state threat actor known as GNU IFUNC! Curses, thwarted again!

robertdfrench 5mo ago
I take your meaning, but I think a threat actor targeting a system without IFUNC would be delighted if it suddenly showed up. It's like finding a website with a file upload form that purposefully supports ../ in paths.

phire 5mo ago

This is barking up the wrong tree. Using IFUNC to patch sshd was kind of elegant, it achieved rootkit like behaviour with a pre-existing mechanism. And sure, it might be possible for a secure daemon like sshd to drop enough privileges that it could protect itself from a malicious dynamically linked library. But IFUNC was not required, neither was systemd. The game was lost as soon as the attacker had arbitrary code installed in a semi-common library. It doesn't have to get linked directly with sshd, it only needed to be linked into any program running as root, at least one time. Most programs make zero effort to sandbox themselves, and as soon as one of those links with the malicious library, it could do anything. Like indirectly targeting sshd by patching its binary on disk (optionally hiding it with a rootkit), or using debug APIs to patch sshd in memory. IFUNC, systemd, and the patched openssh are all irrelevant to the issue, that was simply the route this attacker took to leverage their foothold in libxz. There are thousands of potential routes the attacker could have taken, and we simply can't defend from all of them.

xorcist 5mo ago
It was not essential to the exploit, but that does not mean it was irrelevant. More commonly used libraries are watched harder. The exploit was made much, much, worse by its indirect use by way of systemd. Approximately nobody wanted that feature and it still went in. That's something we need to be able to discuss.
- AshamedCaptain 5mo ago
  But the fact that it was done indirectly from systemd has nothing to do with IFUNC.
belorn 5mo ago
There is always selinux if we want to add protection against arbitrary code running as root. Just because something operate as root does not mean it must have privileged access to everything.
- PaulHoule 5mo ago

liamgm 5mo ago

xz-tools should scrap and reimplemented the code to the safer one , current one have safety and performance issue.

somat 5mo ago

Isn't it the same problem with pam. Some solaris engineer got a little too clever and decided that the modular part of the the auth system needed to be dynamic libs. Now it's all in one process space, hard to understand, hard to debug and fragile. I really like openbsd's bsdauth, I don't know if it is actually any better than pam but because it is moduler at the process level it is possible for mere mortals to debug and make custom auth plugins. Sadly only obsd actually uses it. https://man.openbsd.org/login.conf.5#AUTHENTICATION https://man.openbsd.org/login.conf.5#AUTHENTICATION

countWSS 5mo ago

IFUNC should be implemented by software itself, like switching functions on runtime/compile checks. Why bother having a slower, insecure version that is less flexible than a function pointer? I have to agree with author. Glibc is filled with even more nasty hacks ripe for new exploits.

throwawayqqq11 5mo ago
I agree so much and wished this was the main focus of the debate. It's more a question of why does this exist in the first place and not of how did they abuse it. Building only from source is the minimum required transparency and a CI/CD pipeline able to manipulate the artifact before release takes this away. I remember the outrage, when serde (i think it was) wanted to ship parts as pre-compiled binaries for build performance reasons...
pocksuppet 5mo ago
Less indirection means faster code. If the dynamic loader is already using a level of indirection and you patch into that same indirection instead of adding another, you're not making it slower.

Panzerschrek 5mo ago

> By letting the linker run arbitrary code before main As I know C++ allows running arbitrary code before main too - for constructors of global variables. Does it bring security risks too?

bonzini 5mo ago
It does not, it's actually arbitrary code running during the dynamic loading process, i.e. before _start.
- Panzerschrek 5mo ago
  But what if I have a C++ dynamic library? Does it call constructors for global variables before _start function in the main program starts?
  - bonzini 5mo ago
    _start takes care of calling the global initializers and register the atexit callback for the finalizers. (In practice _start calls __libc_start_main, a libc function that handles all of that).

rurban 5mo ago

Well, also Unicode identifiers, a C11 spec bug, nobody cares to fix. Still in C26, because "users expect Unicode stability", esp. it's bugs.

theteapot 5mo ago

False dichotomy. There was a series of blatant process failures from Github maintainer through Debian package maintainers. IFUNC also bad.

AshamedCaptain 5mo ago

The entire argumentation here is ridiculous. There's a big jump from "IFUNC slightly undermines RELRO" to "IFUNC is the real culprit". You could have gotten all but the same effect spawning a thread from a plain init or C++ constructor. No one should think that any relro, r^x or aslr or anything like this is going to deter anyone who can literally control the contents of the libraries which are linked in. They could, literally, exec a copy of sshd with a patched config if necessary. The title is just clickbait.

chuckadams 5mo ago
I think I triggered the posting of this article in a reply elsewhere, to which you gave the same comment. And dammit, you're totally right, there's lots of other ways to stick arbitrary code into the initialization process at load time. Maybe the real problem is linking dependencies by shoving them into the same address space as whatever is using them and calling it a day. Memory-safe languages can help protect that model against accident, but it still takes just one evil insider to steal the keys to the kingdom.

kristjank 5mo ago

I will still hold the decision to link the biggest possible target on every server against the biggest, most privileged daemon on every server, as not very smart indeed.

bla3 5mo ago

I love the recently added "In Response to Hacker News" section.

robertdfrench 5mo ago
Take my money!!

deleted 5mo ago

[deleted]

esbranson 5mo ago

IDK I do find it funny the linked project readme is dunking on this thread. And I am again going to mention the book Linkers and Loaders by John R. Levine from 1999, I'm not sure if there's anything comparable to it. How else does anyone know anything about this stuff?