From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41737 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhTUq-0002Af-NR for qemu-devel@nongnu.org; Mon, 24 Jan 2011 15:58:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhTUl-00053P-HE for qemu-devel@nongnu.org; Mon, 24 Jan 2011 15:58:44 -0500 Received: from mail-ww0-f41.google.com ([74.125.82.41]:59027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhTUl-00052k-4e for qemu-devel@nongnu.org; Mon, 24 Jan 2011 15:58:39 -0500 Received: by wwi18 with SMTP id 18so3733617wwi.4 for ; Mon, 24 Jan 2011 12:58:38 -0800 (PST) Message-ID: <4D3DE7F8.6080807@gmail.com> Date: Mon, 24 Jan 2011 21:58:32 +0100 From: Stefano Bonifazi MIME-Version: 1.0 Subject: Re: [Qemu-devel] qemu-user: relocating target code weakness References: <4D3D63B3.1030402@gmail.com> <4D3DC1F6.9030800@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040508040406030804080108" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mike Frysinger Cc: Mulyadi Santosa , QEMU Developers This is a multi-part message in MIME format. --------------040508040406030804080108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi! Thank you for your answer! > he is telling you what ELF_START_MMAP is all about. it is the base > address that the linux kernel for that architecture will start giving > out addresses. so when running Linux on an x86 system, the first > mmap() a process does will start at 0x80000000 and move up. > > although looking at the elfload code quickly, it doesnt seem that this > is really used anymore. so it probably can be ignored. Uhmm that makes sense and explains many things like why they can simply consider always possible that the target is allocated at elf_ppnt->p_vaddr, without risking it to clash with qemu-user code.. >> Inside load_elf_binary the call to mmap has elf_ppnt->p_vaddr as required >> starting address (plus alignment) and MAP_FIXED flag. > review the mmap() man page ... MAP_FIXED is always a *suggestion* and > never a requirement. the app must check the return value to see what > the kernel actually gave it. Sorry, wrong! *MAP_FIXED* Don't interpret/addr/ as a hint: place the mapping at exactly that address. [] If the specified address cannot be used,*mmap*() will fail.[] http://www.kernel.org/doc/man-pages/online/pages/man2/mmap.2.html Thank you! Best regards! Stefano B. --------------040508040406030804080108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi!
Thank you for your answer!

he is telling you what ELF_START_MMAP is all about.  it is the base
address that the linux kernel for that architecture will start giving
out addresses.  so when running Linux on an x86 system, the first
mmap() a process does will start at 0x80000000 and move up.

although looking at the elfload code quickly, it doesnt seem that this
is really used anymore.  so it probably can be ignored.

Uhmm that makes sense and explains many things like why they can simply consider always possible that the target is allocated at elf_ppnt->p_vaddr, without risking it to clash with qemu-user code..

Inside load_elf_binary the call to mmap has elf_ppnt->p_vaddr as required
starting address (plus alignment) and MAP_FIXED flag.

review the mmap() man page ... MAP_FIXED is always a *suggestion* and
never a requirement.  the app must check the return value to see what
the kernel actually gave it.

Sorry, wrong!

MAP_FIXED
              Don't interpret addr as a hint: place the mapping at exactly that
              address. [] If the specified address cannot be used, mmap() will fail.[]

http://www.kernel.org/doc/man-pages/online/pages/man2/mmap.2.html

Thank you!
Best regards!
Stefano B.

--------------040508040406030804080108--