From: Stefano Bonifazi <stefboombastic@gmail.com>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: Mulyadi Santosa <mulyadi.santosa@gmail.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] qemu-user: relocating target code weakness
Date: Mon, 24 Jan 2011 23:24:02 +0100 [thread overview]
Message-ID: <4D3DFC02.50104@gmail.com> (raw)
In-Reply-To: <AANLkTimw8ixTeOg93R4q1TM3=0_D9guuL-=K0AiUEJeK@mail.gmail.com>
> how can the ldso possibly prevent clashes ? it has no idea what
> addresses an app will ask for at runtime.
>
> plus, if the kernel is employing ASLR (which isnt uncommon nowadays),
> the load addresses could be anywhere.
> -mike
Well not alone, in my mind ld.so asks the memory manager through calling
mmap where it can map the shared modules inside the process address
space.. the memory manager should know what addresses are free and which
are taken .. then when the process code requires dynamic memory
allocation, it does it again through the memory manager (i.e. malloc)
avoiding of allocating memory where shared modules have been loaded into..
Again with ASLR I think the mmu should be aware of all used memory
slots, avoiding conflicts..
Well your view of random possible clashes maybe is what happens or
happened in Windows systems :D But Linux is supposed to be different,
isn't it?
Best regards,
Stefano B.
next prev parent reply other threads:[~2011-01-24 22:36 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-24 11:34 [Qemu-devel] qemu-user: relocating target code weakness Stefano Bonifazi
2011-01-24 16:29 ` Mulyadi Santosa
2011-01-24 18:16 ` Stefano Bonifazi
2011-01-24 20:00 ` Mike Frysinger
2011-01-24 20:58 ` Stefano Bonifazi
2011-01-24 21:21 ` Mike Frysinger
2011-01-24 21:52 ` Stefano Bonifazi
2011-01-24 22:11 ` Mike Frysinger
2011-01-24 22:24 ` Stefano Bonifazi [this message]
2011-01-24 22:34 ` Mike Frysinger
2011-01-25 0:06 ` Mike Frysinger
2011-01-25 0:18 ` Mike Frysinger
2011-01-25 8:49 ` Stefano Bonifazi
2011-01-25 8:26 ` Stefano Bonifazi
2011-01-24 19:46 ` Richard Henderson
2011-01-24 21:44 ` Stefano Bonifazi
2011-01-24 23:32 ` Mike Frysinger
2011-01-25 8:25 ` Stefano Bonifazi
2011-01-25 1:36 ` Richard Henderson
2011-01-25 8:47 ` Stefano Bonifazi
2011-01-25 8:53 ` Mike Frysinger
2011-01-25 9:58 ` Stefano Bonifazi
2011-01-25 10:47 ` Stefano Bonifazi
2011-01-25 16:22 ` Richard Henderson
2011-01-25 19:03 ` Stefano Bonifazi
2011-01-25 11:06 ` Stefano Bonifazi
2011-01-25 16:26 ` Richard Henderson
2011-01-25 19:49 ` Stefano Bonifazi
2011-01-25 20:53 ` Lluís
2011-01-26 11:07 ` Stefano Bonifazi
2011-01-26 15:38 ` Richard Henderson
2011-01-26 17:44 ` Stefano Bonifazi
2011-01-26 20:17 ` Lluís
2011-01-26 20:19 ` Richard Henderson
2011-01-26 20:33 ` Stefano Bonifazi
2011-01-26 20:36 ` Lluís
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D3DFC02.50104@gmail.com \
--to=stefboombastic@gmail.com \
--cc=mulyadi.santosa@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=vapier.adi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.