Support modules with a lot of sections#280
Conversation
A module might contain more than 65535 sections. Prepare support for such module files by turning relevant fields into uint32_t. Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Read extra fields from section header 0 if needed. Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Codecov Report❌ Patch coverage is
🚀 New features to boost your workflow:
|
| } | ||
| return elf->header.section.offset + | ||
| (uint64_t)(idx * elf->header.section.entry_size); | ||
| (uint64_t)idx * elf->header.section.entry_size; |
There was a problem hiding this comment.
Not sure how easy is for the uint16_t * uint16_t overflow to trigger, but let's keep this change as separate commit.
There was a problem hiding this comment.
Since idx is changed in this PR to a uint32_t and the C standard would therefore use unsigned int for the result, it would be possible.
|
Not 100% sure about the second commit but the first one looks solid. @stoeckmann can you address my minor comment and undraft? |
|
I've kept it as a draft because the linux kernel itself cannot support such modules either (as confirmed in #277). I have used this PR for easier testing/reference to the linked issue. If we want to support possible features of future kernels we could merge this, but right now it's just a possible way of introducing bugs for no practical gain. |
2 participants
It seems that it's possible to compile modules with more than 0xFF00 sections. This leads to different fields in ELF files used to handle such a large amount of sections.
Parse proper fields if necessary.