elf: fixed .text not allocated at 0 on MIPS linux ko.

[DanielBotnik]

When trying to load a kernel module with

l = cle.Loader("./usbcore.ko", auto_load_libs=False, main_opts={"base_addr": 0})
print(a.memory.load(0, 4)) # b'\xe2\xff\x01\xfc'

I've got the wrong bytes b'\xe2\xff\x01\xfc' for .text entry.

This is happens because the .text start is pushed forward by spam sections such as .reginfo and .note.gnu....

In order to fix this in this MR I've done two things:

1. Not add a backer for MIPS_REGINFO
2. Not forward section start remap_offset for those sections.

I dont know a lot about mips, but a point to keep in mind is maybe SHT_MIPS_REGINFO should be treated the same way SHT_NOTE is treated?

I've added the KO I used as well.
usbcore.zip

[rhelmot]

Does it work if you just fix the offset increment and not add SHT_MIPS_REGINFO to this list? based on a cursory googling, it looks like it is desirable for this section to be mapped into memory. https://reviews.llvm.org/D3041

[DanielBotnik]

If I fix only the offset will .text not overwrite .reginfo anyway?

I know IDA doesn't map this section, but maybe its required for dynamic analysis.

[rhelmot]

CLE treats programs with no program headers as fully granularly relocatable. The default behavior is to append every mapped section and just apply relocations. CLE is a pretty competent linker.

[DanielBotnik]

By reading the ABI here https://refspecs.linuxfoundation.org/elf/mipsabi.pdf , I understand that its .reginfo should be allocated but its not required to be allocated at 0x0, Which make sense because the kernel loader doesn't allocate it there.

So I made it the last section to be allocated.

[rhelmot]

Sorry, I just realized something about this issue in general. Why is it important that .text is at offset 0? Can you not replace 0 with a.main_object.sections_map[".text"].vaddr? Also, why are you assuming the compiler has put important data at offset 0 in .text? Can you not consult the symbol table for your needs?

[DanielBotnik]

Maybe I need to rename this PR better, but the Issue I am facing is that I am trying to load the kernel module to a specific address, same address as the kernel loads the module.

But everything is loaded 0x40 bytes forward, because the .reginfo and .gnu.note... sections.

Because of that a.memoey.load give different results then reading the memory from the kernel.

explicitly about .gnu.note is a bug, because in CLE the section is explicitly not allocated, so there is no reason to increase the virtual address of the next section.