From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42399 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhQxq-0004Af-MP for qemu-devel@nongnu.org; Mon, 24 Jan 2011 13:16:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhQxp-0005PM-8J for qemu-devel@nongnu.org; Mon, 24 Jan 2011 13:16:30 -0500 Received: from mail-wy0-f173.google.com ([74.125.82.173]:51432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhQxo-0005PD-T7 for qemu-devel@nongnu.org; Mon, 24 Jan 2011 13:16:29 -0500 Received: by wyg36 with SMTP id 36so4576498wyg.4 for ; Mon, 24 Jan 2011 10:16:28 -0800 (PST) Message-ID: <4D3DC1F6.9030800@gmail.com> Date: Mon, 24 Jan 2011 19:16:22 +0100 From: Stefano Bonifazi MIME-Version: 1.0 Subject: Re: [Qemu-devel] qemu-user: relocating target code weakness References: <4D3D63B3.1030402@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mulyadi Santosa Cc: QEMU Developers 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.