Comment by eqvinox
9 days ago
> https://sourceware.org/bugzilla/show_bug.cgi?id=32653
dlopen and dlmopen no longer make the stack executable if a shared library requires it
I'm not counting intentional breakage to improve system security. I'm not even sure I'd call it an ABI breakage; by a wide definition I guess it is a "change in glibc that makes things not work anymore". You also can't execute a.out binaries anymore, eh. And I don't think I would call something that affects primarily closed source binaries (and mono on i386) a "huge" issue either.
The fix is trivial ("execstack -s <binary>") and doesn't involve any change to installed versions of anything.
> __asm__ (".symver memcpy, memcpy@GLIBC_2.2.5");
A 12 year old forward compatibility issue that is fixed by upgrading glibc, okay. (Note this is the same timeframe as the s390 thing I linked.) I guess people shipping binaries need to be aware of it if they want to support glibc pre-2.2.14. That said, the general rule of shipping binaries is that you need to assume whatever you build against becomes the minimum required version, anything else is a gift.
I think my point about never pinning glibc stands, and how many other things do you know where you need to go back 12 years to find an ABI break?
A few recent examples: many distros changed the flag for emuTLS on Windows, which gcc implemented as a hard ABI break for no essential reason. If you compile for enough platforms, it will print various notes that various alignments have changed in the struct, which has caused grief numerous times in the past few years for people I work with (many of the changes don’t come with notes, they just change alignment since new hardware comes out that has new features which need more and/or there were bugs previously, so they silently change it). There’s also win32 or posix threading, and sjlj vs structured exceptions, all of which are mutually incompatible. Oh, and then don’t get me started on ARM v6 atomics, which is some weird decided-based-on-compiler-flags-to-record-heuristics-detected-during-configure-of-some-auxiliary-header time, instead of using the current target’s ABI
Sure, the ABI does not change at all, if you know in advance where the landmines are. Though it does have quite few, especially for a large project with a huge surface area
I was talking about glibc; none of the things you mention relate to that. (Note glibc is not used on Windows.) I'm painfully aware of some of the breakage GCC occasionally causes (the atomics fall into that — but to be fair ARMv6 is also >10 years ago at this point, unless you're doing embedded, in which case you generally build the whole system anyway and don't care about these breaks.)
Also, just in case it's not clear, glibc has nothing to do with GCC.
You can have one of "they're so serious about forward and backward compat you should remove version pins because things won't ever break" and "well, I'm not counting intentional breaks" but not both.
Why? Is it not normal to have a first priority and a second priority? Does it not make sense for security to come before other things?
I don't know much about glibc's specifics, but in general: Security comes before a lot of things but not before accidental breakage. If you say "our compat guarantees are so strong you shouldn't keep track of versions at all", I expect this to mean that APIs and ABIs will never change, or at least not without a massive awareness campaign and transition plan being announced before - because such a breakage would take out my project or might even introduce new vulnerabilities.
A security update that also does breaking changes is sort of the worst case, because dependents are essentially damned if they apply it and damned if they don't. They can't always be avoided if an API is so insecure it's beyond repair - but then dependents will have to update in their own time because they will also have to fix their own implementations. So this would be an argument for version pins in that case.
2 replies →