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

ELF hash function may overflow

maskray.me

Post reply on HN
Print view View original

31–40 of 41 posts

Re: ELF hash function may overflow

#31

Post by dahfizz »

Joker_vD wrote: post #17
cultureswitch wrote: post #3

Earlier quoted context omitted.

For all its advantages, C is unfortunately so ripe with stuff that any sane guideline would recommend not to do that it can hard to follow through. Though I agree in this case this would never have passed a modern review.

There is a lovely piece of text in the third version of PNG specification: "PNG four-byte unsigned integers are limited to the range 0 to 2^31-1 to accommodate languages that have difficulty with unsigned four-byte values" [0]. Gee, I wonder what languages those may be? [0] https://www.w3.org/TR/2022/WD-png-3-20221025/#7Integers-and-...

C has no problem dealing with a uint32_t. Not sure what you are getting at.

This is more of an issue with languages like java that abstract away integer widths and signs, which is convenient if you're only doing arithmetic but becomes a huge pain when dealing with binary data.

Re: ELF hash function may overflow

#32

Post by dahfizz »

layer8 wrote: post #19
marginalia_nu wrote: post #15

Earlier quoted context omitted.

The code isn't making assumptions, the programmer is.

That’s all the same. Then the code the programmer is writing is wrong because the programmer’s assumptions are wrong. Potato, potahto.

Its not the same. The compiler can protect against code which is incorrect. The compiler cannot do anything to help with code that is correct but does the wrong thing.

Re: ELF hash function may overflow

#33

Post by jameswryan »

omginternets wrote: post #27

I have a question: what should I read for an introduction to the implementation/internals/design of hash functions? I would like to to beyond my current understanding, which is basically “they’re effectively one-way functions”, and be able to participate in discussions of articles such as this one.

For the cryptography & theory? https://toc.cryptobook.us/

For the design and internals of hash functions? The finalists for the SHA3 competition have extensive design documentation. There's an archive at https://web.archive.org/web/20170829225940/http://csrc.nist....

Cryptographic hash functions are designed to resist existing attacks, so you'll want an understanding of differential & linear cryptanalysis, as well as a variety of algebraic attacks. I don't know of a good textbook on the subject, so you might find yourself searching keywords on https://eprint.iacr.org/

Re: ELF hash function may overflow

#35

Post by sylware »

duped wrote: post #29
sylware wrote: post #10

ELF is way too complex and not really adapted anymore. We should start to deprecate DT_NEEDED and make dlopen/dlsym/dlclose (maybe, dlvsym) hard symbols in the loader. And game devs should stop using main() as some genius glibc dev did add a new libc_start_main version in 2.34. Namely, any game executable linked with a glibc from 2.34 will refuse to load on system with a previous glibc. Actually, game binaries should…

Use rpath and ship your dependencies. Even if you dlopen every shared library explicitly you have the same problem. The glibc version problem is not new, you have never been able to rely (safely) that a version of glibc exists that works for your compiled program. This is an example of why containers exist, but unfortunately the problem isn't ELF - it's glibc! And for that matter, glibc also ships the loader. This is…

Yep, the issue is mostly the glibc but ELF does not help. Additionaly, the static libstdc++ is also an issue as it seems not "libdl-ing" any of its system dependencies (did not check if c++ gcc devs fixed that already).

That does not mean ELF is not overkill nowdays. In the case of dynamic linking, deprecating DT_NEEDED to rely on hardcoded (with probably specific relocations) and simplified dlopen/dlsym/dlclose in the ELF interpreter (that would deprecate tls_get_addr() as it would become redondant with dlsym) seems to be a sane cleanup: explicitely split dynamic linking from static linking.

Nowadays mitigation:game devs should go pure ELF64 (no main()) for their binaries and fully libdl-ized. The hard part is to fork a gcc static libstdc++ to libdl-ize its system dependencies (dunno if it was done).

Re: ELF hash function may overflow

#36

Post by gumby »

Back when ELF was designed that architectures larger than 32 bits were extremely uncommon, either obsolete (36 and 40 bit) or expensive and exotic (Cray) so in neither case part of the ELF design space. So not a huge surprise.

I remember thinking at the time that it was an oversight but it took more than another decade for that to even matter.

Re: ELF hash function may overflow

#37

Post by duped »

sylware wrote: post #35
duped wrote: post #29

Earlier quoted context omitted.

Use rpath and ship your dependencies. Even if you dlopen every shared library explicitly you have the same problem. The glibc version problem is not new, you have never been able to rely (safely) that a version of glibc exists that works for your compiled program. This is an example of why containers exist, but unfortunately the problem isn't ELF - it's glibc! And for that matter, glibc also ships the loader. This is…

Yep, the issue is mostly the glibc but ELF does not help. Additionaly, the static libstdc++ is also an issue as it seems not "libdl-ing" any of its system dependencies (did not check if c++ gcc devs fixed that already). That does not mean ELF is not overkill nowdays. In the case of dynamic linking, deprecating DT_NEEDED to rely on hardcoded (with probably specific relocations) and simplified dlopen/dlsym/dlclose in t…

I think what you're advocating for is getting rid of automatic dynamic loading, which is certainly a take.

> go pure ELF64 (no main())

What does "pure" ELF64 even mean? No dependency on libc?

ELF is just an object file format. It doesn't imply anything about how the loader behaves or what features an ELF loader must have, or how that object relates to other ELF objects.

Re: ELF hash function may overflow

#38

Post by sylware »

duped wrote: post #37
sylware wrote: post #35

Earlier quoted context omitted.

Yep, the issue is mostly the glibc but ELF does not help. Additionaly, the static libstdc++ is also an issue as it seems not "libdl-ing" any of its system dependencies (did not check if c++ gcc devs fixed that already). That does not mean ELF is not overkill nowdays. In the case of dynamic linking, deprecating DT_NEEDED to rely on hardcoded (with probably specific relocations) and simplified dlopen/dlsym/dlclose in t…

I think what you're advocating for is getting rid of automatic dynamic loading, which is certainly a take. > go pure ELF64 (no main()) What does "pure" ELF64 even mean? No dependency on libc? ELF is just an object file format. It doesn't imply anything about how the loader behaves or what features an ELF loader must have, or how that object relates to other ELF objects.

Yep, services from the libc would be libdl-ed too. You would have to decide: either you use the machine code in a shared object, or you would statically link that machine code, but the idea is to make those explicit and different, not that current mess.

It means using the sysv x86_64 ABI entry point (which is basically a main()...).

The file format alone is useless, you need the ELF and ABI specs to know how to use properly the information defined by this very file format.

Re: ELF hash function may overflow

#39

Post by lionkor »

mananaysiempre wrote: post #4
lionkor wrote: post #2

If someone checked in that code, it would definitely fail my code review. I understand back in the day it was different, but today there should be a lot of named intermediates. Additionally, `long` and any such keywords should not make it into any commit unless the commit explains 1) why its needed and 2) how, with any standard conforming implementation, it couldnt possibly cause a bug. As always in C programming, th…

Named intermediates for what? This function munges a single hash value, h, and then folds its bits 24 to 31, g, into bits 4 to 7. It implements a mathematical formula, basically, and given it’s a hash, there isn’t much meaning to the contents of any pair of parens in that formula. Perhaps *name++, but any C programmer just thinks “next character of name” when they see that, don’t they? (I’ve seen people code with a l…

if its a mathematical formula, a comment would do it, too

Re: ELF hash function may overflow

#40

Post by omginternets »

jameswryan wrote: post #33
omginternets wrote: post #27

I have a question: what should I read for an introduction to the implementation/internals/design of hash functions? I would like to to beyond my current understanding, which is basically “they’re effectively one-way functions”, and be able to participate in discussions of articles such as this one.

For the cryptography & theory? https://toc.cryptobook.us/ For the design and internals of hash functions? The finalists for the SHA3 competition have extensive design documentation. There's an archive at https://web.archive.org/web/20170829225940/http://csrc.nist.... Cryptographic hash functions are designed to resist existing attacks, so you'll want an understanding of differential & linear cryptanalysis, as well as…

Thank you!
Post reply on HN