Re: [Qemu-devel] qemu-user: relocating target code weakness

[Stefano Bonifazi <stefboombastic@gmail.com>]

Hi!
Thank you for answering me!

> Start address in which address the ELF code section, in reality (not
> under qemu-user) should be mapped. in x86 32 bit it's 08048000, you
> can check it by yourself by executing:
> cat /proc/self/maps
>
Wait, like that I don't understand anything more.. As far as I 
understood when calling mmap from within a process, its result, when no 
error happen, would be the virtual address where the mapping starts.. so 
if I get 0x10000000 from mmap why should it be 08048000 instead??
Inside load_elf_binary the call to mmap has elf_ppnt->p_vaddr as 
required starting address (plus alignment) and MAP_FIXED flag.. so what 
I get is elf_ppnt->p_vaddr as starting map address (if the call does not 
fail) .. so I do not understand where does that address ELF_START_MMAP 
get any role?
> however, as you already know, it might be relocated elsewhere if the
> code is PIC or PIE (Position Independent Executable).
>
Well PIC target code, inside load_elf_binary would have elf_ex.e_type == 
ET_DYN
so the mmap would be not flagged with MAP_FIXED, and the starting 
address of the mapping would be chosen by the memory manager .. again 
ELF_START_MMAP is not used...
> I wrote an article about understanding ELF years ago, here is the URL:
> http://www.linuxforums.org/articles/understanding-elf-using-readelf-and-objdump_125.html
>
Will you believe me if I tell you I printed that document some hours ago 
without noticing you were the author? :)
I downloaded and read so much material from the Internet for studying 
this stuff!!
>> what is start_mmap supposed to point at at the end? Why that
>> static value is chosen at the beginning?
> in qemu 0.13.0, linux-user/elfload.c, lines around 1728 to 1761, you
> will find that start_mmap is kinda an address that is the result of
> mmap operation that will be filled with the code in code section. It
> will be a "hint" on which address the guest code really points when
> dealing with memory address.
>
No, not for my understanding: that code for me searches for a suitable 
mapping area, I can't see info->start_mmap being set anywhere else.. 
surely not among those lines of code
> I dare to guess that, every code executed in the guest...when
> referring to virtual address, will be get substracted by the delta of
> ELF_START_MMAP and real_base.
>
>   It's like "hey, it's written A in the code, but it's mapped in B, ok
> so the delta is A-B, call it X. Then every address in the code should
> be substracted (or added, depending on how you see it) with X, then it
> will point in qemu mmaped VMA"
>
Wrong, at least for what I did understand, and from the tests I did.. I 
compared different input - output assembly code, hardcoded target binary 
addresses like those of static global variables (not of shared modules) 
are not changed at all, producing segmentation faults when forcing a 
shift of the mapping..
> See the codes, read it slowly, you wil get the idea.
I did, I do, I am changing the code for testing it.. fixing it.. but I 
can't see any relocation
> PS: IMHO the real guru is still the one and only  Fabrice Bellard, too
> bad he's out of qemu.
>
How is it possible that the creator of all of this is out?

Thank you very much for your help!
Best regards!
Stefano B.