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

11–20 of 41 posts

Re: ELF hash function may overflow

#11

Post by kevin_thibedeau »

marginalia_nu wrote: post #9
legulere wrote: post #5

Earlier quoted context omitted.

Another perspective is that easily preventable bugs in C arise because the compiler doesn’t stop people from doing them.

I don't understand what it is you expect the compiler to stop. There's nothing actually wrong with the code. It's just written in a platform-dependent manner.

The base integer types have always been open ended since C89. It has always been wrong to assume an exact size when writing code that depends on modular wraparound. The code is wrong.

Prior to stdint.h there was no portable way to address this but new code should be written using the type system as intended. Open ended when the minimum is sufficient and larger storage is inconsequential. Exact size when the algorithm requires it.

Re: ELF hash function may overflow

#12

Post by marginalia_nu »

kevin_thibedeau wrote: post #11
marginalia_nu wrote: post #9

Earlier quoted context omitted.

I don't understand what it is you expect the compiler to stop. There's nothing actually wrong with the code. It's just written in a platform-dependent manner.

The base integer types have always been open ended since C89. It has always been wrong to assume an exact size when writing code that depends on modular wraparound. The code is wrong. Prior to stdint.h there was no portable way to address this but new code should be written using the type system as intended. Open ended when the minimum is sufficient and larger storage is inconsequential. Exact size when the algorithm…

The code isn't wrong, it's platform dependent. It's the assumption that it that is wrong. The code itself if is fine.

Re: ELF hash function may overflow

#13

Post by layer8 »

marginalia_nu wrote: post #12
kevin_thibedeau wrote: post #11

Earlier quoted context omitted.

The base integer types have always been open ended since C89. It has always been wrong to assume an exact size when writing code that depends on modular wraparound. The code is wrong. Prior to stdint.h there was no portable way to address this but new code should be written using the type system as intended. Open ended when the minimum is sufficient and larger storage is inconsequential. Exact size when the algorithm…

The code isn't wrong, it's platform dependent. It's the assumption that it that is wrong. The code itself if is fine.

If the assumptions made by the code are wrong, the code is wrong.

I would agree with you if the code would preprocessor-check ULONG_MAX and #error out if it isn’t the expected value.

Re: ELF hash function may overflow

#14

Post by sltkr »

JonChesterfield wrote: post #8

I chased that rabbit hole briefly and it's not very clear that the hashed value is required to be > It seems obvious that on 32-bit and 64-bit systems, the function should not give different results and a commit to mask off the low bits in an implementation elsewhere. Well, maybe that would be convenient, but overall it seems unimportant. It's necessary for the tool writing the table and the tool reading it to agree…

The behavior is obviously an oversight. I'd bet 1 to 10 that if you chased down the original author he would agree.

No sensible engineer would design a hash function that populates the lower 28 bits of the hash code, ALWAYS leaves bits 28 through 31 clear, and then SOMETIMES sets bit 32, but only rarely and only on certain architectures.

It makes no sense as a conscious design. The logical conclusion is that the intent was to create a 28-bit hash function, and the fact that the provided code sometimes sets bit 32 is clearly a bug.

Re: ELF hash function may overflow

#15

Post by marginalia_nu »

layer8 wrote: post #13
marginalia_nu wrote: post #12

Earlier quoted context omitted.

The code isn't wrong, it's platform dependent. It's the assumption that it that is wrong. The code itself if is fine.

If the assumptions made by the code are wrong, the code is wrong. I would agree with you if the code would preprocessor-check ULONG_MAX and #error out if it isn’t the expected value.

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

Re: ELF hash function may overflow

#16

Post by Joker_vD »

marginalia_nu wrote: post #12
kevin_thibedeau wrote: post #11

Earlier quoted context omitted.

The base integer types have always been open ended since C89. It has always been wrong to assume an exact size when writing code that depends on modular wraparound. The code is wrong. Prior to stdint.h there was no portable way to address this but new code should be written using the type system as intended. Open ended when the minimum is sufficient and larger storage is inconsequential. Exact size when the algorithm…

The code isn't wrong, it's platform dependent. It's the assumption that it that is wrong. The code itself if is fine.

But if the code was written with intention to be platform-independent, and turned out to be platform-dependent... it's the programmer who wrote it is wrong, not the code itself? Or do I misunderstand you completely?

Re: ELF hash function may overflow

#17

Post by Joker_vD »

cultureswitch wrote: post #3
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…

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-...

Re: ELF hash function may overflow

#18

Post by ptsneves »

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…

There is a huge amount of tooling relying on DT_NEEDED for dependency detection. I am not so sure about general purpose Linux, but in the embedded Linux world this would be a disaster. The Yocto system for example would no longer be able to determine the runtime dependencies of generated binaries.

For the static library part, this is such a beaten down argument I just will not argue. I hope you enjoy re-installing your OS every time there is an security update on a library like openssl.

Re: ELF hash function may overflow

#19

Post by layer8 »

marginalia_nu wrote: post #15
layer8 wrote: post #13

Earlier quoted context omitted.

If the assumptions made by the code are wrong, the code is wrong. I would agree with you if the code would preprocessor-check ULONG_MAX and #error out if it isn’t the expected value.

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.

Re: ELF hash function may overflow

#20

Post by dahfizz »

JonChesterfield wrote: post #8

I chased that rabbit hole briefly and it's not very clear that the hashed value is required to be > It seems obvious that on 32-bit and 64-bit systems, the function should not give different results and a commit to mask off the low bits in an implementation elsewhere. Well, maybe that would be convenient, but overall it seems unimportant. It's necessary for the tool writing the table and the tool reading it to agree…

It looks like the ELF standard itself says the hash table uses 32 bit values:

> A hash table of Elf32_Word objects supports symbol table access.

https://refspecs.linuxfoundation.org/elf/gabi4+/ch5.dynamic....

Post reply on HN