4 ms·

I don't think anyone is proposing to eliminate support for --hash-style=both. Correct me if I'm wrong? So at this point, the maintenance burden on glibc is how

I don't think anyone is proposing to eliminate support for --hash-style=both. Correct me if I'm wrong? So at this point, the maintenance burden on glibc is however much effort they want to spend justifying breaking backwards compatibility.

ajross 4y ago
They didn't break backwards compatibility, only forwards. The core issue here is that there is a new format that won't work with old runtime linkers. But the only way to present that format to those old linkers[1] is to take a binary compiled with a glibc version from the last few weeks (!) and run it against on a system where the ld-linux.so is from pre-2006 glibcs. That direction of compatibility is not impossible, but it's not what one normally considers when discussing "breaking backwards compatibility". Fundamentally the only way to provide the kind of compatibility you're demanding, where any level of reverse engineering or parallel implementation must be supported in perpetuity, is to just Never Change Anything At All. [1] With the sole known exception of the "runtime linker" embedded in this EAC product under discussion.
- fweimer 4y ago
  If the required symbol versions are provided by the old glibc version (which is a bit unlikely), it will still work. The internal glibc hash tables are ignored by the link editor, and most distributions override the link editor hash table default anyway. (What changed is that glibc no longer overrides the distribution defaults.)
- brigade 4y ago
  Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. Never Change Anything is far from the ask here. The ask is that when real actual breakage is found, the benefits of keeping said breakage justify not spending the engineering costs to fix backwards compatibility. Near as I can tell, the benefit is 16kB disk space savings, and glibc's engineering cost to maintain compatibility is nothing. Like, another backwards compatibility breakage I saw recently was Graphene switching from 39-bit to 48-bit virtual address space, which also broke games. That has a real measurable security benefit, and actual engineering costs to develop a backwards compatibility story. But they still spent effort to fix breakages.
  - ajross 4y ago
    > Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. No, that's simply wrong. No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue. What happened is that this EAC product had reverse-engineered the internal formats glibc uses to provide the APIs it implements. And that format changed. I repeat what I said elsewhere: it is simply not possible for any software product to anticipate all possible external users of its internal implementation details. What you want, you cannot have. (And I repeat what I said elsewhere too: you don't have this, even on windows. Microsoft breaks things like anti-cheat hackery with every release too, it's just that you don't notice because the proprietary vendors care enough to fix it, where they don't on Linux.)
    - brigade 4y ago
      > No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue. That's obviously not true. The entire story is how a new glibc binary broke existing binaries. > What happened is that this EAC product had reverse-engineered the internal formats glibc Okay I missed this; I thought EAC was parsing the libc binary as per ELF. What was reverse engineered? > it is simply not possible for any software product to anticipate all possible external users of its internal implementation details Correct. Which is why I never asked for stuff that never breaks. What is important is that when stuff is found to break, the breakage and refusal to provide backwards compatibility has a compelling reason. glibc's justifications here are laughable; they're spending more effort to not revert the breakage than it would take to fix. Which is kinda why the story blew up.
    - dark-star 4y ago
      > What happened is that this EAC product had reverse-engineered the internal formats glibc uses No, you got it the wrong way around. EAC has used the well-documented and SysV-standard DT_HASH mechanism. The DT_GNU_HASH is the (almost) undocumented one that they would have to reverse-engineer from GNU ld's source code

ajross 4y ago

They didn't break backwards compatibility, only forwards. The core issue here is that there is a new format that won't work with old runtime linkers. But the only way to present that format to those old linkers[1] is to take a binary compiled with a glibc version from the last few weeks (!) and run it against on a system where the ld-linux.so is from pre-2006 glibcs. That direction of compatibility is not impossible, but it's not what one normally considers when discussing "breaking backwards compatibility". Fundamentally the only way to provide the kind of compatibility you're demanding, where any level of reverse engineering or parallel implementation must be supported in perpetuity, is to just Never Change Anything At All. [1] With the sole known exception of the "runtime linker" embedded in this EAC product under discussion.

fweimer 4y ago
If the required symbol versions are provided by the old glibc version (which is a bit unlikely), it will still work. The internal glibc hash tables are ignored by the link editor, and most distributions override the link editor hash table default anyway. (What changed is that glibc no longer overrides the distribution defaults.)
brigade 4y ago
Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. Never Change Anything is far from the ask here. The ask is that when real actual breakage is found, the benefits of keeping said breakage justify not spending the engineering costs to fix backwards compatibility. Near as I can tell, the benefit is 16kB disk space savings, and glibc's engineering cost to maintain compatibility is nothing. Like, another backwards compatibility breakage I saw recently was Graphene switching from 39-bit to 48-bit virtual address space, which also broke games. That has a real measurable security benefit, and actual engineering costs to develop a backwards compatibility story. But they still spent effort to fix breakages.
- ajross 4y ago
  > Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. No, that's simply wrong. No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue. What happened is that this EAC product had reverse-engineered the internal formats glibc uses to provide the APIs it implements. And that format changed. I repeat what I said elsewhere: it is simply not possible for any software product to anticipate all possible external users of its internal implementation details. What you want, you cannot have. (And I repeat what I said elsewhere too: you don't have this, even on windows. Microsoft breaks things like anti-cheat hackery with every release too, it's just that you don't notice because the proprietary vendors care enough to fix it, where they don't on Linux.)
  - brigade 4y ago
    > No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue. That's obviously not true. The entire story is how a new glibc binary broke existing binaries. > What happened is that this EAC product had reverse-engineered the internal formats glibc Okay I missed this; I thought EAC was parsing the libc binary as per ELF. What was reverse engineered? > it is simply not possible for any software product to anticipate all possible external users of its internal implementation details Correct. Which is why I never asked for stuff that never breaks. What is important is that when stuff is found to break, the breakage and refusal to provide backwards compatibility has a compelling reason. glibc's justifications here are laughable; they're spending more effort to not revert the breakage than it would take to fix. Which is kinda why the story blew up.
  - dark-star 4y ago
    > What happened is that this EAC product had reverse-engineered the internal formats glibc uses No, you got it the wrong way around. EAC has used the well-documented and SysV-standard DT_HASH mechanism. The DT_GNU_HASH is the (almost) undocumented one that they would have to reverse-engineer from GNU ld's source code